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ABSTRACT 


A productivity enhancement study for the U.S. Army 
Information Systems Engineering Command (ISEC) is described. 
Recommendations for improvement and recommendations for 
further study are provided. ISEC has an important mission 
with regard to managing the Army's information resources. 
ISEC is tasked with developing and maintaining the Standard 
Army Multi-command Management Information Systems (STAMMIS). 
Because of resource constraints and increased mission 
requirements, it is essential that ISEC increase 
productivity to meet the information needs of the Army. 

Specifically, this thesis: (1) evaluates the 
traditional software life cycle in contrast with prototyping 
and evolutionary development ; (2) discusses project 
management issues; (3) explains the need for integrated 
software tools; (4) discusses human factors in the software 
development process; and (5) proposes a system for capturing 


and measuring productivity. 
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I. INTRODUCTION 


A. PROBLEMS WITH SOFTWARE DEVELOPMENT 


This study reviews how the U.S. Army Information 
Systems Engineering Command (ISEC) develops and maintains 
the software for the Army's management information systems 
(MIS). The purpose of this thesis is to recommend ways of 
improving productivity throughout STAMMIS development and 
maintenance while maintaining or improving quality. 
Resource constraints, budget and manpower reductions, and 
expanding mission requirements have put pressure on ISEC to 
look for better, faster, and smarter ways of doing business. 
Adding to the difficulty is a whole host of software 
development problems that plague the government and most 
private companies as well. 

The computer-related literature is replete with horror 
stories about software products that have failed in one 
respect or another. Software developers have earned a bad 


reputation for delivering products that do not meet user 


requirements, are late and are over budget. What are the 
factors that are the roots of the so called "software 
crisis?" The major contributing factors are: (1) reduced 


hardware costs; (2) the applications backlog; (3) a shortage 
of skilled software personnel; (4) the difficulties of 
specifying what the software should do; (5) user perception 
problems; (6) the abstract nature of the product; (7) the 
rapid pace of technological change; and (8) curious 


governmental regulations and policies. 


10 


l. Reduced Hardware Costs 


The cost of computer hardware has been dropping 
Significantly during past several years. The average cost 
decrease per year has been 15-30 percent. At the same time, 
the processing power of computers has risen dramatically. 
The resulting cost/performance ratio has improved immensely. 
From 1959 to 1979, for example, it improved by six orders of 
magnitude. To put this in perspective, a unit of processing 
power that cost $1,000,000 in 1959 would cost only one 
dollar in 1979. [Ref. 1: p. 84] Meanwhile, labor costs have 
continued to rise. Today, software costs typically 


represent the largest expenditure for systems. 


2. Applications and Invisible Backlogs 


Government leaders and industry management are 
realizing that information is a resource. It requires 
management, security, planning, and control just like other 
precious assets. Users are becoming more sophisticated. 
There is more hardware to support. These factors have 
fueled demand for new applications at arate faster than 
present programmers can provide them. Many organizations 


have a backlog of programming projects ranging from two to 


four years. Behind this documented backlog of projects is 
often an equally large “invisible backlog” of user 
requirements that are unfulfilled. No cone prepares the 


justification to document these needs because there is no 
hope of getting results in any reasonable period of time. 
[Ref. 2: pp. 281-284] 


3. Shortage of Software Personnel 


There is an acknowledged shortage of skilled 
programmers, analysts, and software managers. Estimates in 


1984 reflected a shortage of software personnel in the U.S. 


I 


of almost 100,000 with the gap expected to widen in the near 
term. [Ref. 3: p. 30] The competition for professional 
software personnel is intense in the private sector. 
Government agencies have a difficult time competing with 


industry for skilled personnel under these conditions. 
4. Problems with the Specification Process 


In software development, the key to writing good 
software iS capturing accurate and complete specifications. 
The user and developer are usually from different technical 
backgrounds. Thus, there is a natural cultural 
communications gap between them. Usually the user does not 
know exactly what he wants. Changes are common as more 
experience is gained building and using the system. The 
traditional software life cycle forces the developer to 
freeze the specifications so that detailed design and coding 
can begin. This results in an unstable foundation on which 
to build the software. [Ref. 4: pp. 59-61} 


5. Perception Problems 


Most people neither understand nor appreciate the 
problems involved in developing or maintaining software. It 


is much more difficult to build software than our intuition 


tells us that it should be. To the user, simple changes 
appear to take much too long to implement. He gets 
frustrated which leads to polarization between "the DPers" 


and other organizational elements. 


6. Abstract Product 


Except. for coding and documentation which are 
typically done late in the software life cycle, there are 
few tangible products by which to measure progress. Lack of 


a physical product makes scheduling and resource estimation 


difiicult. It makes project management risky business. 
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Many organizations must also contract out for their software 
applications because they lack the in-house assets’ or the 
expertise to do it themselves. The effective writing and 
management of software development contracts takes special 


expertise and experience which many organizations lack. 


7. Technological Change 


The growth of the computer industry and rapid rate 
of technological change is unparalleled in history. 
Managers and technicians alike have difficulty staying on 
top of the latest developments in the field. Some react by 
burying their heads in the sand and resisting all change. 


Others attempt to solve the wrong problem by only trying to 


improve traditional methods. If we are trying to actually 
improve productivity, we must look for new and innovative 
ways to solve problems. In this regard, automation should 


be used to the maximum extent possible. [Ref. 2: pp. 11-14] 
8. Government Laws, Regulations, Policy and Traditions 


Another class of problems exists for ADP 
organizations in the government. The laws and regulations 
developed when computers (hardware) were extremely expensive 
are still on the books today. The primary bill governing 
acquisition of computer equipment is the Brooks Act (Public 
Law 89-306). The effect of the Brooks Act has been to 
create layers of administrative actions required to justify 
and procure new hardware. With the incredible improvement 
in the cost/performance ratio of computers, legislation of 
this nature represents a double barrier to productivity. 
Not only does it tie up manpower preparing and staffing the 
necessary documentation to justify the procurement, but the 
benefits of the new technology or methodology are foregone. 
In addition, the government is not able to take advantage of 


the bargains available due to the current economic slump. 
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Certain government policies can be 
counter-productive. A striking example of this is 
Department of Defense (DOD) Directive 5000.29, entitled 
"Management of Computer Resources in Major Defense Systems." 
It requires the use of a DOD-approved higher order language 
in defense systems unless it can be proven that another 
language would be more cost effective for a specific 
application.! The intent was to stem the tide of language 
proliferation. [Ref. 5: p. 15] What it did, however, was 
close the door on fourth generation languages which were in 
their infancy at the time (1976). 

Current civilian personnel office (CPO) policies do 
not normally allow technician positions in the grade of 
GS-13 and above. Those are strictly for management 
positions. This promotes the Peter Principle. Some 
technicians are promoted who really do not want to be 
managers or lack the requisite skills. Others stay in their 
GS-12 positions but develop morale problems which lead to 
decreased efficiency and productivity. For those 
technicians who leave for private industry, it means the 
government incurs increased recruitment costs, increased 
training costs, loss of institutional knowledge, learning 
curve productivity losses, and personnel vacancies. 
Computer technology is complex and changing so rapidly that 
skilled technicians at senior levels are not a luxury but a 
necessity. 

Recent budget cutting schemes have not helped 
recruiting or retention. Announcing a potential five 
percent wage reduction for fiscal year 1986 degraded morale 


of those in the work force. For those considering work in 


‘DOD Directive 5000.31 provides the actual interim list 
of approved languages. Both directives were_issued in 1976, 
before the advent of true fourth generation languages. 
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the public sector, wage reductions add one more strike 
against government employment. 

The work environment for governmental agencies is 
often austere. For many software development agencies, the 
work space is cramped and there are too few conference rooms 
for meetings and walkthroughs. Additionally, the programmer 
to terminal ratio is poor, and the programmers complain of 
poor computer response time. Software development tools, if 
available, are dated and the programmers lack training in 


how to tap their full potential. 


B. THESIS ORGANIZATION AND OBJECTIVES 


The introduction has provided background information on 
software development problems which are applicable to nearly 
all governmental and private organizations. It will serve 


as a framework from which to discuss problems and specific 


productivity issues at ISEC. The U.S. Army Information 
Systems Engineering Command faces significant challenges in 
the near and distant future. To meet their mission 
requirements, internal goals, and objectives, they must 


improve productivity. 

Chapter two provides an organizational overview of ISEC 
and its role in information resource management in the Army. 
The chapter will discuss Army MIS and the role of each major 
player in the process. It will conclude by discussing 


specific productivity problems at ISEC. 


Chapter three looks at productivity measurement. 
Several methods for measuring productivity will be 
discussed. Some metrics are needed to determine whether 
productivity is increasing, decreasing or unchanged. 


Productivity measurement in the software field is neither 
free nor easy. The productivity yardsticks chosen must be 


carefully selected to avoid influencing employee behavior 


15 


that would have a negative impact to the organization as a 
whole. 

Chapter four will discuss the traditional software life 
cycle and the inherent problems associated with developing 
software uSing that methodology. The role of requirements 
definition is absolutely critical for developing software 
that meets users needs in a timely fashion. For reasons we 
will discuss in chapter three, the most expensive problems 


in developing software have historically been in the 


requirements definition phase. An alternate life cycle 
using prototyping is proposed. Prototyping is a departure 
from the traditional software life cycle. The advantages 


and limitations of prototyping will be addressed as well as 
management implications and issues involved in adopting such 
a life cycle. 

In chapter five, we will explore the software 
development environment which includes software tools, 
techniques, and the technologies employed developing the 
software. The need for an integrated software tool set to 
Support software development and maintenance will be 
established. This chapter will also discuss human factors 
and how they relate to productivity. The human factors 
considered will include motivation, awards and incentives, 
employee training, working conditions, and computer 
response time. 

Chapter six is concerned with software management. We 
will discuss project planning and project management, 
resource estimation, contract management, and some general 
management issues. A formal productivity improvement 
program 1S suggested. 

The final chapter will present conclusions reached 
during this Study and Summarize recommendations for 
improving productivity. It will also recommend areas that 


require further study. 
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IIT. SOFTWARE DEVELOPMENT AT ISEC 


A. ARMY INFORMATION MANAGEMENT AND ISEC 


1. Recent Historical Background 


In 1984, a major reorganization in the Army 
hierarchy occurred which will have profound strategic 


implications in the years to follow. 


On May 9, 1984, General John A. Wickham Jr., chief of 
staff of the ‘Army, took the first steps to improve 
information management. . He approved the establishment 
of the information mission area (IMA). This decision 
brought together and integrated the subfunctions of IMA 
- telecommunications, automation to include office 
automation, audiovisual, records management and 
publications. [Ref. 6: pp. 30-33 


Among the changes in the Army's organization included the 
addition of a fifth arm of the Department of the Army (DA) 
general staff, the Assistant Chief of Staff, Information 
Management (ACSIM). The mission of ACSIM is: 


tO improve the management quality and flow of 
information as a principal resource in achieving total 
Army goals, by fully integrating all information 
functions, including information resource management, 
fee es ony: administration and command and control. 


Ref. 7: p 


Another change resulting from General Wickham's IMA 


guidance was the establishment of the U.S. Army Information 


Systems Command (USAISC). USAISC operates and maintains 
assigned information systems in the area of 
telecommunications, automation, office automation, and 


audiovisual [Ref. 8: p. 35]. USAISC was created from assets 
of the U.S. Army Communications Command (USACC), the U.S. 
Army Computer Systems Command (CSC) and several other 


smaller units. 
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The 1984 reorganization also created the Information 
Systems Software Support Command (ISSSC), the forerunner to 
TEC. It was formed from the remaining assets of the 
Computer Systems Command and placed under the leadership of 
USAISC. In June 1985, ISEC was formed by merging the assets 
of the ISSSC and U.S. Army Information Systems Software 
Support Command (ISSSC) and the U.S. Army Electronics System 
Engineering and Installation Command (AESEIC). AESEIC was 
Stationed at Fort Huachuca, Arizona, and most of its 
functions and employees will remain there but under the 
auspices of ISEC. Despite the name change and merger, ISEC 


remains a subordinate unit of USAISC today. 
2. Introduction to ISEC 


The U.S. Army Information Systems Engineering 
Command (ISEC) is a key organization in the Army's effort to 
manage its vast information resources. ISEC has 
responsibility for the technical aspects involved in 


developing, designing, testing, implementing and maintaining 


the Army's Standard Army Multi-command Management 
Information Systems (STAMMIS). 

The command is headquartered at Fort Belvoir, 
Virginia, about 12 miles south of Washington D.C. Several 
hundred employees work in nearby Falls Church, Virginia 


While a major programming directorate is located at Fort 
Lee, Virginia. In addition, ISEC has operational units 
located around the globe with support teams in Hawaii, 
Germany, and Korea. More than 1500 hundred ISEC employees 
(former AESEIC employees) work at Fort Huachuca, Arizona, 
but their primary duties are not STAMMIS related. 

A considerable portion of TSEC resources are 
involved in STAMMIS development and maintenance. Their 


other missions include but are not limited to: 
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l. Managing the Army Information Processing Standards 


(AIPS) program; 


2. Providing technical support to all Army echelons; 

3. Conducting software research; 

4. Developing software standards; 

5. Serving as a developer and evaluator of systems 
software and executive software; and 

6. Monitoring hardware development. 

The size and responsibilities placed on ISEC are 
impresSive. It ais responsible for information systems 
design, development, installation and test to include 
hardware, software, and systems integration. [Ref. 9: p. 


38] ISEC employs well over 4000 workers most of whom are 
civilians. It is comparable in size to major software 
houses and computer companies. Approximately 1000 employees 


are in programmer or analyst positions supporting STAMMIS. 
3. The Evolution of Army Information Management 


During the past 20 years, the Army has modified its 
information structure several times. As the Army's 
information needs evolved and computer-based information 
systems technology advanced, the Army's’ philosophy for 
managing information has also evolved. The IMA 
reorganization demonstrates a commitment by the Army to 
treat information as one of its most precious resources. 
The consolidation and integration of information functions 
under one manager makes sense because of the 
interrelationships between them. 

Richard Nolan wrote a landmark article in the 
Harvard Business Review (1979) on the stages of evolutionary 
growth that organizations experience with data processing. 
Nolan describes how organizations move through rather 


distinct stages from stage l (initiation) through stage 6 
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TABLE I 
STAGES OF DP GROWTH - NOLAN 


STAGE 1: INITIATION 


RS of low level operational systems in 
a functional area 


No overall planning or control 
STAGE 2: CONTAGION 
Growing demand for and proliferation of applications 
Innovation encouraged 
Applications developed in isolation 
Low level of planning and control 


Managers cannot obtain information for decision 
making 


Proliferation of incompatible and redundant data 
STAGE 3: CONTROL 

Planning and control become formalized 

Shift occurs in management orientation from 

management ọf computers to management of 

the company s data resources 


Users arbitrarily held accountable for the cost 
of data processing; Users become frustrated 


STAGE 4: INTEGRATION 
Existing applications retrofitted into data bases 


Increased demand by users 


“< Redundancy of data 


STAGE 5: DATA ADMINISTRATION 
Organization wide strategic planning 
IRM emphasized 
Tailored planning and control systems 
STAGE 6: MATURITY 
Applications portfolio is completed 


Structure mirrors the enterprise and the information 
flow in the company 


Information Engineering is largely completed 
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(maturity).? [Ref. 10: pp. 115-126] These stages differ in 


the kinds of applications being developed, the control over 
the information system function, and by the degree of 
planning involved for future applications. Ref. lI: «pp. 


269-72] Table I is a summary of Nolan's six stage model. It 
is normal for an enterprise to reorganize (such as the 
Army's evolution) as it attempts to control and make full 
use of its information resources. 

Where does the Army fit in Nolan's Model? Although 
the boundaries are somewhat ill-defined, the Army is 
somewhere between stages 3 and 5. Strategic planning and 
Information Resource Management (IRM) are being 
emphasisized, thus, one could argue that the Army is 
beginning data administration (stage 5). On the other hand, 
a strong case could be made that the Army has never left 
stage 3. Users are frustrated with the applications backlog 
and management has frequent difficulty obtaining the 
information they desire for decision making. Additionally, 
the Army has not retrofited existing applications into data 


bases. 


B. THE STAMMIS DEVELOPERS 


There are three main participants involved in the 
development of STAMMIS: the functional proponent (FP), 
ISEC, and the user. The functional proponent is normally a 
Department of the Army (DA) staff element such as Deputy 
Chief of Staff, Personnel (DCSPER). The FP is responsible 
for the functional software specifications of a particular 
STAMMIS. They also assist with functional aspects 
concerning STAMMIS design, development and testing. ISEC is 


“This is a_ refinement of an earlier article by Gibson, 
as F., and Nolan, Richard L., ‘Managing the Four Stages 
O EDP Growth, Harvard Business Review, V. oe 
January--February 1974, pp. 66-76. — 
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responsible for the technical Specification. design, 
development, coding, configuration management ,testing, 
implementation, and maintenance of the STAMMIS. ISEC is 
known as the application system developer (ASD) for STAMMIS 
Software. [Ref. 12: p. A-1] 

The Army's STAMMIS or management information systems 
(MIS) can be divided into three main functional areas. They 
are shown in figure 2.1 along with the functional proponent 
and examples of each. Each functional area is Serviced by a 
Separate ASD within ISEC. In total, ISEC has developed and 
supports over 60 different MIS. 

The sum of all the programs that comprise the more than 
60 STAMMIS are on the order of 15-20 million lines of code. 
This library has been in development for about 20 years. If 
industrial yardsticks apply, ISEC has spent between one and 
two billion dollars developing and maintaining this code. 
[Ref. 13: p. 1] 


Functional Area/Example Functional Proponent 
l. Financial Systems eee Comptroller of 
STANFINS the Army (COA) 
STARCIPS 
2. „Logistical Systems T m E DCSLOG 
SAILS 
SARSS 
ULLS 
3. Personnel and Force 
E Systems. ee eee DCSPER 
SIDPER 
VFDMIS 
VTAADS 


Figure 2.1 STAMMIS Functional Areas, Examples and Proponents. 
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C. BASIC PROBLEMS AT ISEC 
l1. Preface 


It is the opinion of the author that Information 
Systems Engineering Command is well managed. Employee 
morale is favorable. ISEC has a sound training program. 
They are fortunate to have a commander who is technically 
qualified and understands the issues and problems in systems 
development and integration. However, in the software 
development business, the challenges are formidable, varied, 
and many. 

The problems that beset ISEC occur in most other 


information systems departments or software development 


organizations. Chapter one considered generic software 
development problems - all are evident to some degree at 
TSEC. There are additional factors bearing on the software 


development efforts at ISEC. They are discussed in the 
following subsections. Although the role of information is 
changing in the eyes of Army leadership, there are many 
obstacles to overcome before achieving Army goals for 


information resource management. 


2. Specification Problems 


As mentioned earlier, the key to quality software is 


capturing accurate and complete specifications. For STAMMIS 
software, the functional proponent is responsible for the 
functional specifications. In the unlikely event that the 


FP knew exactly what it wanted, they often lack the training 
to write clear, complete specifications. The geographical 
distance between the STAMMIS key players slows coordination, 
fosters cultural differences, and increases 
misunderstandings and development time. In addition, the 
end user has historically been only marginally involved in 


the specification process. 
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STAMMIS have been fielded which did not meet 
customer needs, were not used, or were difficult to use. 
There are, indeed, recent examples of just this happening. 
Mn Son a STAMMIS was developed for the military police 
(named MPMIS) after considerable pressure was applied by the 
FP to meet specific deadlines. An audit followup was 
conducted four months after the system was’ fielded. The 
findings revealed that virtually no one was using the MPMIS. 
[Ref. 14] This has frustrated all parties involved, has had 
a negative effect on peoples' perceptions of ISEC and 


dampened ISEC employee morale. 
3. Political Conflicts 


The FP sometimes makes arbitrary decisions when 
requesting engineering change packages (ECPs) without 
consulting ISEC for a resource and time estimates. Because 
STAMMIS are file processing systems (vice data base 
processing systems), it is not uncommon for an apparent 
small change to actually be a time consuming venture. This 
is due to the ripple effect the change has on other portions 
of the program or system. This has caused further 
alienation for two reasons. First, it frustrates the 
programmers who are forced to work overtime to meet 
arbitrary deadlines. Second, if a deadline should be 
threatened, the FP is angry for what seems like the 


incompetence of ISEC to handle the smallest of changes. 





4. Lack of Skilled Professionals 


ISEC has a difficult time competing for computer 
programmers and analysts in the Washington D.C. area. They 
rarely are able to hire college graduates, much less, 
computer science graduates. Employees at ISEC give two 
primary reasons for this: (1) the government does not pay 


competitive wages to attract these people, and (2) lack of 
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aggressive recruitment by the servicing CPO. There is 
evidence in the literature to support the claim that 
government wages may be lagging behind that of the private 
sector in the Washington D.C. area. [Ref. 15: pp. 58-69] It 
should be noted that compensation packages are frequently 
bundled quite differently making direct comparison of wages 
dangerous, at best. [Ref. 16: pp. 27-38] 

ISEC is forced to "grow their own" and they do just 
that through an intern training program. Frequently, after 
their obligation to the government is completed, they leave 
for better paying jobs inthe private sector. Some are 
hired by software houses or businesses that do contracting 
work for the Army. These firms pay them a few thousand 
dollars more which eventually gets charged back to the Army 


along with a standard overhead markup of 100-150 per cent. 
5. Personnel Reductions 


The Army is undergoing the process of fielding four 
active duty light infantry divisions from internal assets to 
meet worldwide threat scenarios. Despite this buildup, Army 
leadership (perhaps for good reason) chose not to request an 
increase to the Army's end-strength from Congress. 


Organizations such as ISEC are frequently called on to be 


the "bill payers" for manning such units. The result is 
that ISEC is asked to do more with less. Several managers 
interviewed expressed concern over these reductions. They 


rf? 


Survive through a positive "can do" approach to their work. 
8 P PP 


But at some point, if it has not already been reached, 
Meme s ability to meet mission requirements will be 
threatened. 


6. Contract Management Problems 


Manpower reductions coupled with the low experience 


level of the programmers and the demands placed on ISEC by 
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the functional proponents has created a sizeable backlog of 
projects. It has forced management to contract out for many 
projects. This, in and of itself, may not be bad. There 
are those who argue that the provisions of Office of 
Management and Budget (OMB) Circular A-76 mandate more 
STAMMIS work being contracted out. The problem with this, 
however, is that ISEC has not exhibited the expertise to 
properly write and manage such contracts. 

The Vertical Force Development Management 
Information System (VFDMIS) contract is a classic "how not 
to do things" and "if something can go wrong, it wile 
VFDMIS is a complex STAMMIS expected to be in the 
neighborhood of one million lines of code (LOC) - no small 
venture for the finest of software developers. Work on 
VFDMIS began in 1974. The contract was let to a small 
business contractor, ASG, despite the knowledge that VFDMIS 
was to be the largest and arguably the most complex MIS in 
the Army. The contractor originally lacked the necessary 


expertise for the project and was hampered by tremendous 


personnel turnover. In short, VFDMIS has suffered of a 
history of disappointments, technical difficulties; and 
problems. 

Incredible as it may seem, there have been no 


deliverables presented to ISEC at the end of any contract 
year. If the contract was cancelled tomorrow, the Army 
would have little to show for this 11 year, multi-million 
dollar fiasco. It doesn't appear likely that the Army will 
have an operational system for at least a few more years. 
Coding on the system has only recently begun. [Ref. 17] The 
chances appear good that the Army will field another 


obsolete system with obsolete technology. 
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fe Lack ort Standardization 





ISEC is required to develop and maintain several 
versions of a STAMMIS. This is caused by multiple 
environments in which the software must run. If the Army 
could agree on a Standard operating system such as Multiple 
Virtual System (MVS), an IBM operating system, the potential 
long-run savings would be significant. There would be some 
initial hardware and training costs involved. Some field 
commanders may not wish to accept the short-run productivity 
loss that such a change would entail. Further, by 
standardizing the operating system to MVS, it may stimulate 
complaints about locking yourself into only a handful of 
vendors. This is a difficult issue, however, and one that 


ISEC is exploring. 
8. Organizational Turbulence 


The initial section of this chapter described ISEC's 
two major reorganizations in the past 12 months. These 
changes exact atoll on the productivity of the employees 
which is difficult to precisely gauge. Adjusting to new 
relationships and incurring new responsibilities are a part 
of this transition process. These organizational changes 
Should be of long-run benefit to the Army but there is large 
payment required today in terms of short-term productivity 


losses. 


9. File Processing Shortcomings 


Traditionally, STAMMIS are "stovepipe file 
processing systems" that are application specific along 


functional lines. Current STAMMIS fail to take advantage of 


data base technology. The advantages of data base 
processing are well known; Table II is a summary those 
advantages. These advantages may not be fully experienced 
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in every system. In fact, there are shortcomings of data 
base processing. Among them are: (1) DBMS systems are 
expensive; (2) they are complex; (3) backup and recovery are 
more difficult; and (4) there is an increased vulnerability 
for failure. [Ref. 18: pp. 1-7] 


TABLE II 
ADVANTAGES OF DATA BASE PROCESSING 


e More information can be obtained from the same 
amount of data. 


e New requests and one-of-a-kind requests are more 
easily implemented. 


e Reduction of data duplication resulting in fewer 
cases of conflicting reports. 


e Program/data independence is achieved thus the 
data is compatible for other programs. 


e Data management is facilitated. 


e DBMS, generally allow more affordable 
sophisticated programming. 


ISEC has several forward-thinking employees who 
realize the benefits of data base processing. ISEC have 
sent a formal request to USAISC to establish a STAMMIS 
corporate data base |Ref. 19]. USAISC believes the idea has 
merit but wants ISEC to tie their efforts to the Army 
corporate data base, an ACSIM initiative [Ref. 20]. This is 
probably a reasonable idea but because of the lead times 
involved in designing these systems, it means the current 
STAMMIS will continue to be file processing systems for 


several years. 
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D. CONCLUSION 


The pitfalls to software development are staggering but 


not unsolvable. In this regard, there are four basic 
approaches to improving productivity at TSEC. These 
involve: 


l. Improving the techniques and methodologies employed 
developing the STAMMIS (Chapter 4); 

2. Utilizing the benefits of technology to develop the 
system more effectively and efficiently (Chapter 5); 

3. Creating a positive work environment for the 
employees at ISEC (Chapter 5); and 

4. Improving the Management of STAMMIS (Chapter 6). 


The next chapter defines productivity and explains produc- 
tivity measurement in general. It discusses specific 
productivity measurements for software development and main- 
tenance. It also discusses implementing a performance meas- 
urement system at ISEC. The remaining chapters discuss the 
four basic approaches mentioned above to provide suggestions 
for improving productivity while simultaneously improving 
(or at least maintaining) the overall quality of the 
STAMMIS. 
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III. PRODUCTIVITY MEASUREMENT AND IMPROVEMENT 


Ay INTRODUCTION 
l. Overview 


Productivity is a favorite buzzword of the 1980s. 
Data processing literature is laced with articles on 
different aspects of the subject. The acute programmer 
shortage and the great demand for software products have 


made productivity an especially critical issue in software 


development. Published goals at ISEC state "Foster 
Productivity" as a principal organizational objective. What 
is productivity? How do you foster productivity? These 


questions and related issues are discussed in this chapter. 
2. What Productivity is Not 


Productivity is often confused with production. It 


does not necessarily follow that the greater the production, 


the greater the productivity. Surprisingly, a 19/2 Conii 
Harris poll revealed that 2/ percent of executives 
interviewed held this erroneous’ view. In addition, one 


third of all college educated and professional respondents 
were likewise ill-informed. [Ref. 21: p. 41] The following 


description should help clarify the distinction between the 


two: 


Production is concerned with the activity of producing 
goods and/or services. 


Productivity is concerned with the efficient utilization 
of resources 


inputs) in produci d d o 
(outputs). Ape 55? p. A ACTAS BLUES O ee 
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There is also confusion between the related concepts 
Of efficiency, effectiveness, and Productivity. 
Effectiveness reflects how well a result met its objectives; 
efficiency reflects how well the resources are utilized to 
accomplish the results. Thus productivity is really a 
combination of both effectiveness and efficiency since 
effectiveness is related to performance while efficiency is 


related to resource utilization. [Ref. 22: p. 6] 


3. Productivity and Software Development /Maintenance 


We have talked about productivity throughout this 
paper but have yet to define it. Alvin Toffler, author of 
The Third Wave, discusses the problems of defining 


productivity: 


The first problem is the definition of productivity. It 
is one of the Se ee and one of the most treacherous 
of economic concepts. It was designed for a world of 
material production, when. you could count how many 
workers and how many hours it took to turn out how many 
skirts or copper bars. As we have moved to what I ve 
been calling a Third Wave economy, more and more of our 
@eeput Consists of information, Services, experience. 
More and more the consumers own actions affect the 
efficiency of the producer, In addition, we have peer 
to appreciate that economic productivity is frequently 
more an. artifact of accounting and of ermissible 
Ape ne tization_ tnan of anything else., Oe ave 
tremendous problems with the very term productivity. 
MRet. 23: p. 14] 


Perhaps turning to the dictionary will serve as a starting 
point. Webster's Third New International Dictionary defines 
productivity as: 
a) The physical output per unit of production effort; 
b) The degree of effectiveness of industrial management 
in utilizing the facilities of production; especially 


the effectiveness in utilizing labor and equipment. 


Dr Irving Siegel, author of Company Productivity, defines 
productivity as: 
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a Bey ae ae S quantity of output to quantity oi 
ef. 


os of 
IES 
How is productivity defined for software development 


and maintenance? One expert defines it as follows: 


Programmer productivity is generally defined as the 
quantity of work produced by an individual programmer in 
a unit of time... The definition implies the speed of 
programming, including the related tasks such as program 
design,. coding, testin and documentation. The 
definition can be modifie to use an expense or cost 
unit instead of a work unit.. In addition, the 
definition should be extended_to include program quality 
measurements. [Ref. 24: p. 


The following section will discuss programmer productivity 


in some detail with the emphasis on measurement aspects. 


B. MEASUREMENT FOR IMPROVEMENT 
l. Why We Should Measure Productivity 


Capers Jones, author of several articles on 
programmer productivity and measurement, noted that 
preceding all the great advances in science in the 19th and 
20th century were earlier advances in measurement 
instruments and measurement techniques. [Ref. 25: p. 33M 
Many authors speak of the evolution of software development 
from an art toa science. But are we there yet? Lord 


Kelvin's often quoted passage is appropriate here. 


When you can measure what you are s carine about, and 
express it in numbers, you know something about it; but 
when you can not measure it, when you cannot express it 
in numbers, your knowledge is of a meager and 
unsatisfying kind: it may be the beginning of 
a er but ou have’ scarcely in zonr thoughts, 
advanced to the stage of science. ` (Ref. 26: p. 16] 


Perhaps we are not there yet but we are making 


progress. One thing is certain - unless we have systematic 
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methods to measure productivity, it will remain simply a 
buzzword with little or no real meaning. ISEC has done 
little to measure productivity as an organization. This 
makes it extremely difficult to gauge progress towards 
ISEC's goal "Foster Productivity.” 

We measure productivity in the software development 
and maintenance process primarily for management purposes. 
Productivity measurement provides information for planning, 
controlling and evaluating the entire process as well as the 
individual projects within the process. For planning, it 
provides management with information useful to estimate 
resource requirements. For control, planned resource 
estimates can be compared against actual expenditures. 
Variances can be analyzed and appropriate action can be 
taken to correct deficiencies. For evaluation, measurement 
systems provide valuable feedback on individual works, 
projects and the organization as a whole. [Ref. 27: pp. 
135 

Most authors agree there are many potential benefits 
which accrue by measuring productivity. The benefits 
reflect a positive view of the purposes of productivity 
measurement. Table III summarizes the major benefits. 

Lowell Arthur, author of Programmer Productivity, is 
a strong believer in measuring productivity for software 


development. Arthur contends that: 


One of the keys to improving productivity and quality is 
the ability to measure them. Software metrics provide a 
ardstick of system quality and project productivity. 

ithout quantitative and qualitative measurement, you 
can. t tell if your developing system is a lemon ora 
eca oiled machine. Furthermore, when it is operational 
you won t be able to tell what makes it a lemon or such 
an a neering marvel. You won t_know where or what to 
eor how fto recreate the excellence of a previous 
System. You ll be no better off than blind men trying 
to describe an elephant. [Ref. 28: p. 
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TABLE III 
POTENTIAL BENEFITS OF MEASURING PRODUCTIVITY 
ORGANIZATION 
e It helps determine if the oreani Ze tome oes eee 
its money s worth. 
e It can improve the internal company climate. 
MANAGEMENT 
Data collected can_ help estimate programming 
resources for scheduling a project. 


It facilitates management control. 


It can help indicate potenti high-cost, main- 
e 


tenance prone programs during t development. 


It can serve as a mechanism to help appraise and 
possibly reward employees. 


PROGRAMMER 


e It provides feedback on performance to employees. 


e It can serve to motivate employees to higher 
performance levels. 





2. Units of Measurement 
a. Overview 


There are two basic units of measurement, work 


units and cost units. Work units measure things like speed 
of programming; an example of which is lines of code (LOC) 
per man-month. Work units can be deceiving. They must be 
carefully defined and used cautiously to ensure 
comparability. An example of a cost unit is programmer-days 
per 1000 LOC. Because of inflation, cost units are not 
always stable. It is often advisable to use standard 
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dollars fixed to some base year instead of actual dollars to 


facilitate comparison when using cost units. [Ref. 24: pp. 
18-19] 

There are three basic types of productivity 
measures: partial factor productivity, total factor 
productivity, and total productivity. Partial factor 


productivity is the ratio of output to one class of input. 
Total factor productivity is the ratio of net output (total 
output minus intermediate goods and services purchased) to 
the sum of the associated labor and capital (factor) inputs. 
Total productivity is the ratio of total output (not net 
output) to the sum of all input factors. [Ref. 22: p. 7] 

Management should be aware of some of the 
potential advantages and limitations of each type of 
measurement. Table IV and Table V provides a short Summary 
of the advantages and limitations, respectively, to help in 
this regard. [Ref. 22: pp. 7-10] 


b. General Problems with Measuring Productivity 


There are several problems involved in the use 
of productivity measures. These center around the 


measurement of inputs and outputs and their abilities to 


measure efficiency. What is measured depends on the purpose 
(e.g. management intent) and use of the measurement. If 
management is interested in efficiency, when measuring 


inputs for use in a productivity measure, it is desirable to 


ensure that only the inputs that are actually utilized in 


the production process are used in the measure. This sis 
especially important for the labor inputs. It implies, for 
example, that only time worked should be utilized in the 
measure instead of time paid. Although time paid is of 
interest for total cost purposes, elements Such as 
administrative time should be separated out. Most 
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TABLE IV 
ADVANTAGES OF THE 3 BASIC_TYPES OF PRODUCTIVITY 
MEASURES 


PARTIAL PRODUCTIVITY MEASURES 


e They are easy to understand. 
e Data is easy to obtain. 
e Productivity indices are easy to compute. 


e They are easy to sell to management because of 
the above 3 advantages. 


e Some EE roductivity indicator data is 
available industry-wide. 


e They are good diagnostic tools to pinpoint areas 
for productivity improvement, if used along with 
productivity measures. 

TOTAL FACTOR PRODUCTIVITY MEASURES 

e The data from company records are relatively easy 

to obtain. 


* They are usually appealing from a corpor icek- Con 
omist S vlew. 


TOTAL PRODUCTIVITY MEASURES 
e A more accurate representation of the. real 
economic pacos of an organization is obtainable 
because they consider all the quantifyable output 
and input factors. 


e Tf used with partial measures, they can direct 
management attention in an effective manner. 


e Sensitivity analysis is easier to perform. 


e They can be easily related to total costs. 


organizations will probably want to track both time worked 


and time paid, however, as a pure efficiency measure, time 
worked is preferable. This separation will allow management 
to focus their efforts more appropriately. Care must be 
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TABLE V 
LIMITATIONS OF THE 3 BASIC TYPES OF PRODUCTIVITY 
MEASURES 


PARTIAL PRODUCTIVITY MEASURES 


If used alone, they can be very misleading and 
may lead to.costly mistakes. 


They do not have the ability to explain overall 
cost increases. 


They tend to shift the blame to the wrong areas 
of management control. 


TOTAL FACTOR PRODUCTIVITY MEASURES 


When. material costs form a sizable portion of 
total product costs, they are not appropriate. 


Only labor and capital inputs are considered. 


Data for comparison purposes is relatively diffi- 
cult to obtain. 


TOTAL PRODUCTIVITY MEASURES 


e Data for computations are relatively difficult to 
obtain at_ the product and customer levels, unless 
data collection systems are designed for this 
purpose. 


e As with the partial and total factor measures, it 
does not consider the intangible factors of 
output and input in a direct sense. 





taken in the aggregation of inputs. Using labor as an 
example, different skills such as key punch operator versus 
a systems analyst, perform entirely different tasks. As 


such, their inputs should only be aggregated when they occur 
within a particular department. Where possible, it is 
preferable to measure inputs in terms’ of physical units 


rather than value units. [Ref. 27: pp. 37-38] 
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Exactly what should be measured can, indeed, be 
a problem. Convenient output measures are not always 
available in public sector organizations that provide a 
service where no acceptable definition of their outputs 
exist (e.g. national defense). In these organizations, most 
of the output measures in use are actually inputs to further 
processes - many are weak at best. In cases where inputs 
and outputs cannot be precisely measured, productivity 
measures become susceptible to manipulation and gaming. 
This implies that the control and evaluation phases of 
management may focus on faulty indicators. [Ref. 27: mE 
38-39] 

Another related problem exists concerning how to 
deal with the quality of inputs. Idealy, to equitably 
compare various output levels, quality should be hela 
constant. In reality, quality is rarely constant. In 
addition, quality changes are often difficult to measure. 
[Ref 22720 poe 

Dr. Barry Boehm cites a Weinberg study which 
found that programmers will tend to maximize (or minimize) 
whatever is being measured. Five different programming 
teams were given the same assignment but were given 
different directions about what to optimize while doing the 
job (e.g. minimize the number of statements or minimize the 
amount of memory required by the program). Four of the five 
teams finished first with respect to the objective they were 
asked to modify; the other team finished second. None of 
the teams performed consistently well on all objectives. 
The conclusion to be drawn from Weinberg's experiment is 
that management must carefully define the objectives for 
their programmers taking into consideration the conflicting 
nature of goals - programmers will try to otimize whatever 


is being measured. [Ref. 29: pp. 20-21] 
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A related problem is that programmers have been 
known to "pad" their output in effort to look better. There 
are many ways to do this. If lines of code per man-month is 
a critical management measure, programmers will tend to 
write programs that are longer than necessary without regard 
to machine efficiency. Programmers may even include 
duplicate loops or use other methods soley to increase their 
lines of code. “Thus, we must always be aware that 
productivity measures are often SuSceptible to gaming. This 
is another reason why management must be very careful 
chosing: (1) what they measure; (2) why they measure it; 
(3) how they measure it; and especially (4) what management 


does with the results of the measurement. 


In addition to the anomalies above, a few final 
words of caution and guidelines about productivity 
measurement are condensed below from various articles. The 


articles warn that: 
l. Taking a measurement changes the system being 
measured (The Hawthorne Effect); 
Comparison of results may be meaningless; 
Results are sometimes paradoxical and misleading; 
No single measurement tells the whole story; 
Each measurement has its pros and cons; 


Measuring productivity is not free; and 


yY OF Un f£ W fo 


All measures are relative. 
c. Measuring Programmer Productivity and Quality 


(1) Preface. Keeping in mind the above 
discussion of productivity measures in general, we can now 
begin to discuss the measurement of programmer/project 
productivity. The difficulties of measurement are best 
verbalized by people who have actually struggled with the 


issue. Trevor Crossman complains: 
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Programmer productivity is a dilemma. On the one hand 
we want_to control projects by knowing exactly when and 
where all slippages occur, we want to know 1f using a 


new. methodology really is „beneficial. We despise 
estimates that are based on gut feel but it a Eee 
that if we are to measure the productivity o our 


programmers we have to identify project. variables and 
calculate their influence on our programming staff, make 
subjective assessments of the envisaged complexity of 


programs and the predicted ability of rogrammers 
CUATE terminology that has no indus ry-accepted 
definitions, measure the quality. of our programmers 
work, and base programmers performances. on. project 


estimates (which. are arrived at unscientifically, 
anyway). 


t may be easier to say it just cannot be done. 
Ref. 30: p. 144] 


Crossman's comments demonstrate some of management's 
frustrations concerning productivity measurement. Some 
progress has been made though; many metrics have been 
proposed, tested, and found useful. These include 
measuring: (1) lines of code (LOC) per some labor unit; (2) 
functions which the user performs when utilizing the 
program; (3) functions which the program performs; (4) 
completed projects; and (5) quality and complexity. We will 
explore these major methods in the rest of this section. 
Clearly, many variations of these techniques exist. 

(2) Lines of Code. Traditionally, software 
development organizations measured LOC per some unit of 
labor such as man-days or man-months. Many authors have 
Suggested several problems with this general approach, 
however. Table VI is a summary of the shortcomings of LOC 
as a productivity measure. 

Based on the strong objections to using 
LOC per labor unit as a productivity measure, one might 
conclude that it is useless. This is not so. Many 
companies, such as IBM, still use it as a management tool to 
gauge productivity despite its inherent shortcomings. Why? 
One major reason is that it is easy to measure. In fact, in 


many cases, the process can be automated. But because some 
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TABLE VI 
PROBLEMS WITH LINES OF CODE AS A PRODUCTIVITY MEASURE 


There iS no standard definition of LOC. 


LOC measurement is subject to gaming. 


LOC _ focuses attention on coding which is only 
10-20% of the total software process. 


Comparisons across rogramming languages and 
companies are meaningless. 


Higher level languages are penalized. 


LOC does not address quality. 





measure iS easy to obtain is no reason, in and of itself, to 
use the measure. The critical question is "what is 


management's intent for use of the measure?” 


Arthur recommends measuring executable 
lines of code (ELOC) to avoid the problem of lack of 
standardized definition of LOC. For organizations such as 


ISEC that program almost exclusively in COBOL, measuring 
ELOC amounts to counting only COBOL's verbs - statements 
that do something. Arthur provides a program in Appendix C 
of his book Programmer Productivity which automates’ the 


measurement process. Arthur contends that: 


ELOC rovides the. only . valid measure otm Coding 
productivity currently available [Ref. 28: p. 133]. 


He freely admits, however, that ELOC suffers many of the 
same limitations as LOC. Yet management awareness and 
prudent judgement can overcome most of the limitations. 
feet. 28: pp. 132-135] 
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(3) Program Functions. Crossman, while 
working at the Standard Bank of South Africa, proposed and 
tested a productivity measure based on the number of 
functions within a program. He divided the number of 
man-hours spent during system development’ by the sum of all 
programs in the system. [Ref. 30: pp. 144-5] Note that this 
really represents an inverse productivity measure. As in 
the case of LOC, program functions measure an input into the 
software development process instead of an output. 

Precisely defining exactly what a function 
is may be a problem partly because Crossman's research 
involved only highly structured programs. In his article, 
"Taking The Measure of Programmer Productivity", he defines 


functions as: 


that section of the program that performs. only_ one 
activity, such as AS fields, cone ae values, 
setting up a print line, validating a record, etc. has 
only one entry point and one exit point; conforms to the 
permited logic structure of structured REO aie. and has 
about 5-50 source statements [Ref. 30: p. 145]. 


The only factor that significantly 
affected the time to develop an application was the number 
of functions within a program. Crossman determined that he 
could disregard all other project variables for estimating 
the development time except for the use of "breakthrough 
technology" (e.g. new data base technology or a new 
operating system). In those cases where new technology was 
employed, the development time doubled indicating a steep 
learning curve adapting to new technology. The management 


implication is that program functions may be a wUseens 


planning and resource estimating tool. On the other hand, 
l *Crossman defiņes development. time as design, code, 
inspection and unit test but excludes system test which he 


feels rarely is a development time/cost driver. 
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program functions suffer many of the same limitations as 
other methods. [Ref. 30: pp. 145-147] 

(4) External Attribute Functions. Allan J. 
Albrect, working at IBM's DP Services Organization, 
pioneered another approach to the programmer productivity 
measurement dilemma. Albrect proposed a measure based upon 


the external attributes or functions that a software product 


involved. The general approach is to count the following 
features in an application: (1) user inputs; (2) external 
inquiries; (3) external outputs; (4) master files; and (5) 


system-to-system interfaces. [Ref. 31: p. 102] 

The subtotals of the individual five 
factors are weighted (by trial and error) by numbers 
designed to reflect the function value to the user. The 
weighted totals are then added. Additional adjustments can 
be made to account for a particular project's quirks. For 
example, if an application is particularly complex, the 
total can be increased by some percentage. The result is a 
dimensionless number defined in "function points" which 
Albrect has found to be an effective relative measure of 
function value. The actual meaSure used is hours worked per 
function count, another inverse productivity measure. 

Albrect asserts that function value is 
programming language and technology independent. The 
measure of external attribute functions offers the 


considerable advantage of actually attempting to measure the 


results of the entire software process. In this respect, it 
corresponds more closely to a true productivity measure. It 
is also less subject to gaming than other methods. One 


author points out: 


What is significant. is that function points do not 


contradict what would have been speculated, lendin 
Ey to this concept of measurement. Withou 
this credibility, 


| future productivity assessments would 
ee ssp. [Rer]: p. 1081 
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Another author counters with: 


The disadvantage of function points is that they are 
UES ae and often misunderstood. Many people perceive 
a function point figure to represent function delivered 
to the user. In, fact, it, represents the amount of 
function imbedded in the specific design of the system; 
much of the imbedded function may be invisible or not 
utilized by the user. Indeed, different designs meeting 
the same requirements may have widely different function 
point counts. [Ref. 32:` pp. 13451554 


(5) Completed Projects. Another possible 
measure is completed projects per unit of labor. The 


definition of project would need clarification but the 
method does appear easy to implement and use. To make it a 
viable measure, managers would have to ensure that employees 
were given projects of equal difficulty over some period of 
time. If employees were left to select their own projects, 
typically only the short, easy or interesting projects would 
get done. Difficult projects with potential high payoff to 
ISEC may lay dormant at the bottom of some in-box. Some 
type of weighting scheme could be used based on management's 
judgement as to the difficulty or importance of the project. 
The requirement to balance the load equitably among’ the 
employees is no easy management task and may offset the ease 
of implementation and ease of use advantages. [Ref 27 
47] 

(6) Complexity and Quality Metrics. The work 
of Maurice H. Halstead (1977) and Thomas McCabe (1976) has 
given birth to a another view of productivity measurements. * 
Halstead developed a number of metrics that are computed 
from easily obtained properties of the source code (e.g. the 


total number of operations in a program). The metrics he 


*A complete description of these metrics is beyond the 
scope of this thesis. They can be found in most modern text 
books on software design or software engineering including 


Richard Fairley's Software Engineering C a 
McGraw-Hill, ee T9353: ma Tee een wOoncepts, 
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proposed were a program length metric, a program volume 
metric, and a program effort metric. Followup research has 
proven that Halstead's effort metric is well correlated with 
the observed effort required to debug and modify small 
programs. Program effort thus appears to be a measure of 
interest for software maintenance. [Ref. 33: pp. 323-324] 
McCabe observed that the difficulty of 
understanding a program is strongly influenced by the 
control flow for that program. McCabe's metric is based on 
graph theory but really amounts to adding the number of 
logical operators (AND, OR, and NOT) to the number of 
decisions. To keep errors to aminimum, he recommends an 


upper bound of 10 as the maximum complexity for the control 


graph of an individual routine. McCabe's original research 
demonstrated strong correlation between cyclomatic 
complexity, ease of testing and the reliability of the 
routine. Thus, McCabe's metric can help identify those 
modules that are candidates for rewrite. Preta 3.332 pp. 
324-325] 


Arthur offers two complexity measures for 
COBOL programs. The first metric he suggests is to sum all 
ene CALL, PERFORM, SORT, MERGE, COMPUTE, INSPECT, and 
GENERATE statements and divide that result by LOC/100. 
Dividing by the 100 normalizes the metric for ease of 
comparison with other programs. (There is nothing magic 
about the number 100, it could just as well be 50.) TRIS, 
he claims, provides a metric called ‘function density’ which 
is actually a complexity measure. The higher the functional 
density, the more functional and modular the program. 
[Ref. 28: pp. 135-6] 


Arthur's second complexity measure counts 


the number of decisions in the program. The sum of the IF, 
PERFORM UNTIL, PERFORM TIMES, and SEARCH WHEN counts gives 
the total number of decisions in the module. This 
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represents a basic measure of program complexity and 


testability. This sum is then divided by the total LOC in 
the program, and again is normalized by dividing by 100. 
This metric is known as "decision density"; it provides the 


number of decisions in each 100 LOC. Arthur claims decision 
density is a highly representative measure of complexity, 


"the cruel task master of maintenance programming." 


In addition to measures that focus 
primarily on the coding phase, there are other quality 
metrics for documentation, testing, etc. Productivity 
measures for documentation include: (1) cost per 


documentation page; (2) document pages per unit of time; and 


(3) document cost per 1000 LOC. Productivity measures for 
testing might include: (1) test cases developed and 
executed per unit of time; and (2) cost per defect. Note 
that these are partial factor productivity measures. As 


such, they probably can and should be used but only with 
extreme caution - they are all susceptible to manipulation 
and gaming. They may influence employee behavior, depending 
on management and the incentives program established, to 
maximize some ratio at the detriment to the total process 
and the organization. 


It 1S appropriate to end this section with 


a quote from Tom Gilb, author of Software Metrics. Gilb 
says: 
Again, we are forced to recognize that, although many 
readers might be tempted to argue "I can’t go around and 
measure everything. My programmers have too much work 
to do. already, the Int roducEelonmee appropri gaa 
measuring techniques does not cost, it saves. t is nee 
a luxury, it is a necessity. {[Ref. 34: p. 64] 


It 1S amusing to note that Gilb dedicated his book to all 
the people who have patiently explained to him why it is 


to . 4 a : z 
impossible", "impractical", or "uneconomical" to measure 


software quality! 
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C. IMPLEMENTATION OF A PRODUCTIVITY MEASUREMENT SYSTEM 
l. Overview 


The previous sections have discussed the "why" and 


the "what" of productivity measurement; we now proceed to 


the "how" - that is, implementing a system to monitor 
performance. Why doesn't every organization have a 
measurement system if there are so many benefits? As 
previously mentioned, the collection and analysis of this 
information is not free. It requires machine, people, time, 
and other resources. Automation of the process may help to 


lower administrative costs but it doesn’t eliminate them. 
Another problem is people's natural resistance to change. 
In addition, some managers and employees may feel threatened 
working in an environment where their actions are recorded 
and documented. These human issues must be given 
appropriate attention. But as Gilb pointed out above, 
tracking productivity information is cost-effective in the 
long-run - it is a necessity! 

Capturing this information may be helpful for 
reasons other than gauging performance. A measurement 
system cam provide quantitative justification of resources 
required for particular projects. Under the commercial 
activities program, all non-mission-essential activities are 
subject to private sector provision. For software 
development and maintenance, this program would require ISEC 
to bid on particular projects along with commercial software 
houses. Such bids must be auditable, which implies that 
productivity information must be quantitatively-based and 
verifiable. [Ref. 27: p. 49] 


2. Implementing the Measurement System 


The following subsection discusses the 


implementation process for an actual measurement system at 
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ISEC. It has been adapted from and is based on the ideas of 
Irving Siegel, author of Company Policy. [Ref 21: PP: 
45-53] Implementation of a measurement system consists of 
the following 6 basic steps: 

Top Management Commitment; 

Task Force Selection and Charter; 

Marketing the Program; 


Collection of Information; 


Nn A U NBH 


Designing the System; and 
6. System Installation and Evolution. 


Each phase is discussed below. 
a. Top Management Commitment 


As with most systems, unless the top brass is 
commited to it, the chances for success are dismal. To 
obtain top level commitment, it may be prudent to establish 
a pilot program in one of the programming directorates. The 
idea should be to collect data on a number of software 
projects and evaluate several measures using this data. 
Guidance should be solicited during this initial stage 
concerning any restrictions or constraints which top 


management may feel are appropriate. 
b. Task Force Selection and Charter 


The second step is the selection of a task force 
or steering committee and developing the organizational 
charter. Members should be strategically chosen. They 


should represent a broad-class of organizational skills 


required for software development and maintenance. Some top 
level participation is advisable. The charter should be 
formulated with an overall objective of devising a 


monitoring scheme that satisfies company needs and meets the 


stated time and cost constraints. 


48 


c. Marketing the Program 


The third step is carefully marketing the intent 
of the program to all levels at ISEC. The fears and 
anxieties of managers and the rank-and-file employees need 
to be quelled before the rumor mill begins to churn. 
Briefings, seminars, fact sheets, and the ISEC newspaper 
Should discuss the program and ¡its purpose completely and 
candidly. ISEC should consider designating productivity 
officers at various levels to Serve as liaison up and down 


the chain. 


d. Collection of Information 
This fourth step may be more accurately 
described as "doing your homework." ISEC's data bases and 
skill resources should be studied. The lessons learned and 


Suggestions for improvement from the pilot program should be 
documented for later use in designing the actual measurement 
system. The programs of other government agencies should be 
ascertained and evaluated. In particular, the General 
Accounting Office (GAO), the General Services Administration 
(GSA), the National Bureau of Standards (NBS), the National 
Security Agency (NSA), U.S Air Force and Navy should be 
surveyed to learn from their experiences. Neglecting these 
resources would be a serious’ blunder. Another possible 
source of information are the productivity offices that each 
of the military services has. A thorough and careful 
analysis of what information is currently being collected 
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should be conducted. Things often overlooked such as who 


will train management and the employees?" and "what will the 


training consist of?" need to be addressed during this 
phase. It is possible that ISEC does not have the in-house 
assets to accomplish these myriad tasks. It may be 


necessary to seek the assistance of a consultant. 
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e. Designing the System 


The main objective of the task force is to 


arrive at a first-generation monitoring system that 
satisfies ISEC needs and constraints. This implies the 
system is not static but evolutionary. All the lessons 


learned from the pilot system should be considered to make 
the transition process as smooth and painless as possible. 
ISEC employee suggestions and the results of surveying other 
federal agencies should also be considered. Automation of 
the administrative accounting and record keeping system 
should be "designed in" to the maximum extent possible. A 
preliminary users manual should be written to guide the 
operators of the system. It should describe the nature of 
the system and its structure as well as covering the 


measurement process itself and the procedures for carrying 


it out. 
f. System Installation and Evolution 

It is probably wise to designate the first six 
months or so as a trial period to work out the bugs, refine 
the procedures and seek suggestions for improvement. The 
process is much like developing STAMMIS for users. It is an 
iterative process. Not everything can be prespecified in 
advance. The trial system will stimulate new and better 


ways to measure productivity. 


D. SUMMARY 


This chapter provided definitions for productivity. 
Productivity was distinguished from production, efficiency 
and effectiveness. The benefits for measuring productivity 
were explained and the problems with monitoring productivity 
were discussed. some guidelines were included concerning 


the use of productivity measures. Specific productivity 
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measures for software development and maintenance were 
evaluated in light of their advantages and disadvantages. 
Finally, a strategy for implementing a productivity 
measurement system at ISEC was suggested based on the ideas 
of Irving Siegel. 

The next chapter discusses the problems with traditional 
methodologies for obtaining accurate and complete 
specifications. Prototyping and evolutionary development 
are explained and recommended as an alternative to more 


conventional techniques. 
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PROTOTYPING 


A. PROBLEMS WITH THE TRADITIONAL SOFTWARE LIFE CYCLE 
1. The Traditional Software Life Cycle 


Internal documents at ISEC reveal that the average 
development time for standard systems is five to seven years 
[Ref. 35]. This translates to users that are handcuffed by 
inefficient and ineffective systems. It means managers are 
not able to get the decision making information that they 
need. With the continual rapid advancements in hardware 
technology, it also means the system will be fielded on 
obsolete hardware. 


What causes a software development time of five to 


seven years? Software development is a complex process so 
there are no simple answers. Reviewing the software life 
cycle may be helpful. Figure 4.1 is a representative 
version of the traditional software life cycle. [Ref. 36: 


p. 29] Figure 4.2 shows the phases of the DOD system life 
cycle. [Ref. 2: p. 302] 


As these figures show, 


The software development cycle is often presented as a 
Sequential set of well defined phases, each with 
Specific products and_ reviews, which provide the 
necessary Structure to facilitate management and control 
by the developer/project manager. [Ref. 37: pp. 74-5 


Despite this phased approach, the end result has frequently 
been software that is late, over budget, or does not meet 
user needs. 

Many software professionals feel the life cycle 


itself is the root of the problem. Daniel McCracken and 
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Michael Jackson, authors of "Life-Cycle Concept Considered 


Harmful", put it this way: 


The life cycle a e Pee peruates „our failures so far, 
as an industry, to build an effective bridge across the 
communications gap between end-users and , systems 
analysts. In many ways it constrains future thinking to 
fit the mold created_in response to failures of the 
past. [Ref. 38: p. 30] 


Along these same lines, G. R. Gladden, Supervisor of Quality 


Assurance at Honeywell's Build Services Division, warns: 


I am of the opinion that the concept of a | ‘software 
life-cycle is no longer helpful, indeed may be harmful 
to our software development profession. In its various 


forms the life cycle has sought to describe the software 
development process as iterative events within the major 
tasks of design, implementation, test, etc. One begins 
Bemyisualize the development process as a sequence of 
tasks 'waterfalling “into one, another while within each 
task modifications occur iteratively as a better 
understanding of the system is acquired. These 
interactions work together to extend project schedules, 
invalidate designs, alter test_ requirements and to 
generally infuriate customers. Ref. 39: p. 35 


ISEC, in an effort to diminish the "software 
crisis’, has tried a variety of techniques and methodologies 
that have helped improve the situation. They attacked the 
problem by standardizing their efforts and formalizing the 
process. They attempted various structured approaches 
including structured analysis. Voluminous specification 
documents were "ping-ponged” back and forth between the FP 
and ISEC. Regrettably, major problems remained. Why? 

The specification document is the foundation on 
which the software is built. It is fundamental to the 
conventional software life cycle. James Martin, author of 
the world's best selling computer books, believes that there 
are serious problems with specification documents and the 
process by which they are validated. Table VII lists the 


major problems of the process. [Ref. 2: p. 7] There are 
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many who share Martin's thoughts. McCracken and Jackson 


write: 


systems requirements cannot, ever be stated fully jįn 
advance, noť even in principle, because the user doesn t 
know them in advance - not even in principle. To assert 
otherwise is. to ignore the fact hat the development 
process itself changes the users perceptions of what is 
possible, increases his or her insight into applications 
environment and indeed often_ changes that environment 


itself., We suggest an analogy with the Heisenberg 

Uncertainty Principle: any system development activity 

inevitably changes the environment out of which the need 

for the system arose. Systems development methodology 

must take into account that the user, and his or her 

eee ae environment, change during the process. 
ef. cp 


TABLE VIT 
PROBLEMS WITH THE SPECIFICATION PROCESS 


It lacks precision. It cannot be converted into 
computer code without many assumptions an 
1nterpretatilenss 

It contains many ambiguities and inconsistencies. 


It is usually incomplete. 


It is often so Bane and boring that key managers 
ey 


do not read it. T read only the summary. 

It is often misinterpreted by both sides. — Often 

TES da think they understand it but in fact 
o not. 


Sometimes much trivia and motherhood are added to 
the document. Both sides_ understand this. IE 
increases the comfort level, but has zero value. 


The specification document is not designed for 
successive refinement _as the problems become 
better understood. It is intended to be a 
complete document which users sign. 
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NOTE: NONLINEAR 
SCALE 


REQUIREMENTS DESIGN OPERATION 


LIFE CYCLE PHASE IN WHICH 
ERKOR DETECTED AND CORRECTED 





Figure 4.3. Relative Cost to Correct Errors 
in Software Life Cycle. 


What do these specification problems mean in 
dollars? Figure 4.3 shows the relative cost of correcting a 
requirement or design error as the product progresses 
further into development. It helps illustrate the high 
level of risk involved with the traditional software life 
cycle. When errors are found late in the cycle, 
requirements have to be revalidated, design redone, software 
and system retested, and documentation rewritten. Iso yy oye’ 
article "Seven Basic Principles of Software Engineering,” 


Dr. Barry Boehm supports this idea when he writes: 


There is one single message about developing reliable 
software which out weighes all the others. It is to get 
the errors out early. 


One of the most prevalent and costly mistakes made on 
software projects today is to defer the activity of 
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detecting and correcting software problems until late in 
the DS: There are two main reasons why this is a 
mistake: 


l. Most of the errors have already been made before 
coding begins; and 


2. The later an error is detected and corrected, the 
more expensive it becomes. 


[Ref. 40: p. 9] 


The cost to correct increases dramatically as we move from 
phase to phase. Errors traced to specification documents 


are very expensive to fix. 
2. Maintenance Considerations 


We need to look beyond just software development and 
consider the entire software life cycle. The goal is to 
minimize total life cycle costs. Minimizing only software 
development costs may cause suboptimization and possible 


higher total costs. 


It is well established that maintenance activities 
consume a large portion of. the total life cycle budget. 
It is_not uncommon for software maintenance to account 
for 70 percent of total life __ cycle costs _(with 
development receiving 30 percent) [Ref. 33: p. 311]. 


Figure 4.4 is a graphic portrayal of these facts. 
Software maintenance? involves developing enhancements, 
adapting to new environments, and correcting problems. 

The following quote from Software Engineering 
Concepts captures the essence of the activities in the 


maintenance phase: 


software prodni enhancements may. involve providing new 
functional capabilities, improving user displays and 
modes of interaction, upgrading external documents and 
internal documentation, Or upgrading performance 


`. Some software engineers prefer the term evolution to 
maintenance. Although evolution may be a more accurate term 
for this phase, the more traditional term will be used here. 
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MAINTENANCE DEVELOPMENT 
60-307. 20-907. 


Figure 4.4 Maintenance - The Largest Cost Driver. 


Characteristics of a system. Adaption of software to a 
new environment may involve moving the software to a 
different machine, or for instance, modifying the 
software to accommodate a new telecommunications 
Peoeeocol or, an additional disk drive. Problem 
Correction involves modification and revalidation of 
software to correct errors. [Ref. 33: p. 3 


It has been estimated that 60 percent of the 
maintenance budget involves enhancements while adaption and 


correction each account for 20 percent of the maintenance 


effort (See Figure 4.5). If the above statistics are 
correct, we can conclude that over 40 percent of all life 
cycle costs are for product enhancements. Why such a high 
percentage for enhancements? A major contributing factor is 
that formal, Structured techniques have not provided 
software developers with complete or accurate design 
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Figure 4.5 Relative Effort for Maintenance Activities. 


specifications.? A methodology or tool that could provide 
accurate and complete specifications would reduce the effort 
necessary for product enhancement. This, in turn, woui 


decrease maintenance costs thus reducing total life cycle 
costs. 


To increase productivity, ISEC must change their 
traditional way of developing STAMMIS. This rather bode 
Statement accepts "the challenge" of the Commander of 


USAISC, Lieutenant General Emmett Paige Jr., who declared: 


“Few would argue that unstructured code is. better than 
structured code Structured techniques have created 
software that is easier to understand and maintain. 
Structured techniques have been less successful however, 


providing. clear, concise, consistence and complete design 
reduir ements: 
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We need to change the aaa do business - challenge the 


oy we ve always done 1 E innovative ways 
ay i 


eld systems sooner [Ref. 41]. 


ISEC must seek to bridge the communications gap between the 
functional proponent, the ASD, and the user. Traditional 
requirements analysis techniques have resulted in a document 
that few people read or understand. Bernard Boar, author of 


Application Prototyping, makes the following comment: 


If you are serious about alleviating the productivity 
problems with application development, there is only one 
question that deserves La “attention: What technique 
offers the highest probability of EOS a clear, 
em ect, consistent and validated requirement statement 
of the user's need? [Ref. 42: p. 29] 


Boar's answer is, of course, prototyping. We will explore 


prototyping in subsequent sections in this chapter. 


B. PROTOTYPING AND EVOLUTIONARY DEVELOPMENT 


As the previous section has illustrated, the net result 


of improper requirements analysis are increased costs, 


duplicated efforts and a poor product. A definition of 
requirements and specifications is probably overdue. 
Requirements provide an understanding of the general 


applications area and should include a list of desirable 
features that the system should contain. Specifications 
record precisely what the function of the system is. It is 
derived from the requirements. Specifications normally do 
not involve "how to" implementation details. [Ref. 433 . p. 
4 | 

A prototype is nothing more than a model or pilot 
system. Prototyping is not a new concept. Scientists and 
engineers learned long ago that models and pilot systems are 
necessary and useful learning tools which lessen the 


inherent technical risks associated with developing new 
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systems. Software developers have been slow to use this 
approach when building application programs. 
Fred Brooks, respected author of The Mythical Man-Month 


and project manager for the IBM 360 operating system, writes 


The_management question, therefore, is not whether to 
build a Pee System and throw it away. You will do 
that. . The only question is whether to plan in_advance 
to build a throwaway, or to promise to deliver a 
throwaway to the customers. | Seen this way, the answer 
is much clearer. Delivering that throwaway to the 
customer buys time, but it does so only at the cost of 
22 for the user, distraction for the builder while 
they do the redesign, and a bad reputation for the 
product that the best redesign will find hard to live 
own. 


Hence lan to 
[Ref. 44: p. 116] 


throw one away; you will anyhow. 
There are two basic views of prototyping. One is the 
Fred Brooks' view. That is, the prototype is seen asa 
requirement specification-, technical feasibility-, and/or 
requirements validation tool. It's a throwaway and nothing 
more. The other view of prototyping is known by several 
names; incremental development, iterative development, 
iterative refinement, and evolutionary development are the 
more common names. Dr.: Boehm describes incremental 


development as: 


Development of a software product in several expandin 

increments „of functional capability as a means o 

Beco Ae eee development risks, of smoothing out the 
project s personnel requirements, and of getting 
Something useful out early [Ref. 40: p. 8]. 


The throwaway view of prototyping is the older of the 
two views yet it represented a radical change to software 
development practices in the early and mid 1970s. Except for 
the most progressive software developers, very few accepted 
prototyping as a development methodology. With the advent 


of fourth generation or non-procedural languages in the late 
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1970s and early 1980s, the second view of prototyping became 
technically feasible. Yet as Boar wrote in 1984, 
"Prototyping of large systems would not have been possible 
just two years ago." Thus, as advancements have been made 
in fourth generation languages, the real value for 


applications development has only recently been established. 


C. ADVANTAGES OF PROTOTYPING 


The literature on prototyping suggests both qualitative 
and quantitative benefits of prototyping. Table VIII 
summarizes the major advantages suggested by authors who 
have hands on experience with prototyping. 

Experience to date shows that prototyping is usually 
faster than traditional methods but not always. The main 
benefit of prototyping is the role it plays bridging the 
communications barriers in the development process. There 


exist cultural differences between the user, ASD, and the 


FP. These are the result of technical and organizational 
differences. The prototype helps to create a common 
framework from which to work. Specifications are better 


because they are in a form the user can realistically 
validate. It frees the user and the FP from being forced to 
Sign off on reams of paper that they vaguely comprehend. 
[Ref. 45: pp. 38-46] 

Because the user is an active participant, there are 
Significant benefits resulting. The man-machine interfaces 


can be tested early inthe life cycle and adjusted as 


necessary. As users gain experience with the prototype, 
they can provide valuable feedback for changes and 
enhancements. Users can change their mind; specifications 


are not locked in concrete so early in the process that good 
ideas are frozen out. There is a natural bonding that 


occurs during the development, feedback, and testing 
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TABLE VIII 
ADVANTAGES OF PROTOTYPING 


e Provides a_ facility to permit assessment of the 


impact Gl eee system on the whole user 
environment. 

e Forces a user centered approach. |. Users’ can 
change their mind. User acceptance is easier to 
obtain. 

e Permits early testing of human/machine 
interfaces. 


e Helps alleviate Broject communication problems 
caused by cultural differences. 


e Provides a medium for validating requirements. 
e Requires fewer programmers. 

e Potentially decreases development time. 

e Reduces technical risks. 


e Reduces maintenance costs thus reducing life 
cycle costs. 


e Stimulates programmers and increases their 
motivation level. 


process. Users perceive (quite correctly) that they are an 
integral part of the system. In addition, users develop a 
"warm feeling" for the end product, hence, their confidence 
increases which facilitates acceptance of the system. 
[Ref. 46: pp. 15-18] 

This author believes that the greatest potential 
benefits of prototyping will be for large systems 
development. These are the projects with the longest 
development lead times and have the highest degree of risk 
associated with them. An incremental approach where the 
heart of the System is developed first and then 


embellishments and refinements are added should reduce 
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development risk and total life cycle costs. Designs and 
ideas that do not work out can be Scrapped at minimal cost 


and embarrassment to the developers. 


D. PROTOTYPING LIMITATIONS 


Despite the numerous advantages of prototyping, it does 
have limitations. Prototyping may frustrate users that have 
seen a working model. Some users may want to implement the 
prototype directly - something it is not normally designed 
o do. Experience with prototyping at the Del Monte 


Corporation resulted in the following observation: 


mes development learned that they (the user) thought 
the application was 90% complete. But this was not so - 
the prototype only simulated the. operation of the 
system. Users had little concept of the amount of work 
needed to complete a prototype - aes validation and 
editing routines, implementing the atabase design, 
adding security, backup, and recovery features, turnin 
it over to operations and maintenance PSAE TETS, an 
so on. Users often become impatient when development of 
these back end portions appeared to be taking too 
long. [Ref. 47: p. 2] 


Del Monte used two approaches to counteract this user 


reaction. First, they "phase implement" the system creating 


the critical portions initially and adding functions 
incrementally. Second, they have end users assist in the 
programming. They also try and reduce the system to the 
smallest version that will Sold gl meet basic user 
requirements but may lack the "bells and whistles." 


[Ref. 47: pp. 2-3] 

Another limitation of incremental development is that 
prototypes are not developed with efficiency in mind. The 
idea is to minimize human resources by developing the 
software faster and using less programmers. It is possible 
to build hybrid systems today which take advantage of the 
efficiency of COBOL and the coding speed of fourth 


generation languages. 


65 


TABLE IX 
LIMITATIONS OF PROTOTYPING 


Prototyping does not necessarily result in 
shorter development time. 


Because of the. iteration process, resource 
planni and time estimating procedures are 
difficurt. 


There exists a possibility that something major 
may be left out of the system. 


The issue of when to stop the iteration process 
is not clear. 


Some uSers may get bored or irritated if the 
iteration rocess takes too long or if the 
initial prototype is way off the mark. 


Some users may want to implement the prototype 
directly. 


Prototyping may require a substantial investment 
for the procurement of software tools, training 
costs and additional computer hardware. 


Prototyping __does not always use computer 
resources efficiently. 


Prototyping is not appropriate for all types of 
applications. 


Programmers may feel threatened by prototyping. 





Prototyping does not allow the software developer to 
throw away software engineering principles. There is still 
a need to do a preliminary requirements analysis prior to 
building the prototype. The larger system environmental 
constraints will eventually have to be reckoned with. 
Developers who ignore documentation during evolutionary 
development will discover in the maintenance phase that 
their "shortcuts" may actually increase total system costs! 
Rigorous structured techniques are still important to ensure 


all of the bases have been covered. 
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Other authors have suggested additional limitations of 
prototyping. Table IX is a summary of prototyping 
limitations. 

Whether all the above complaints, issues and limitations 
are valid is a matter of debate. Regardless, prototyping is 
not a panacea. Its limitations must be considered before 


applying it to a particular problem. 


E. A BRIEF OVERVIEW OF THE PROTOTYPING LIFE CYCLE 


Figure 4.6 shows a proposed software development life 
cycle which acknowledges the effect of prototyping on the 
development process [Ref. 45: p. 105]. The Feasibility 
Phase is the same as in the traditional life cycle model. 
During the feasibility phase, typically a preliminary 
cost/benefit analysis is done as well as determining the 
applicability of a computer-based solution. If the 
application iS appropriate, the Prototype Phase seeks to 


develop user requirements. 


FEASIBILITY 
PROTOTYPE 
OPTIMIZATION/COMPLETION 


CONVERSION 


OPERATIONS/MAINTENANCE 





Figure 4.6 The Prototyping Life Cycle. 
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Prototypes initially ignore many larger, system 
constraints. The Optimization/Completion Phase brings the 
prototype into harmony with any operational constraints. It 
is usually neither feasible nor prudent to implement a 
prototype directly. Software that is appropriate for 
prototyping may not be appropriate for production 
architectures. Efficiency, data base size, and transaction 
processing rates are considerations for the actual systems 
which are largely ignored by the prototype. The Conversion 
Phase addresses these types of issues. [Ref. 45: p. 104] 


The final phase, Operations/Maintenance is similar to 


its counterpart in the conventional life cycle. Iteration 
does not magically stop when the system is fielded. Laws 
and regulatory changes, user needs, and environmental 
changes will cause the STAMMIS to evolve. It is important 
to consider what changes in the software are likely to be 
made when the prototype is built. The software should be 
written to accommodate such change and thus reduce 


maintenance costs. [Ref. 48: pp. 226-235] 


F. PROTOTYPING APPLICABILITY AND IMPLEMENTATION AT ISEC 


Not all system structures are good candidates for 
prototyping. Applications that are extensively 
batch-oriented are probably inappropriate for prototyping. 
Algorithm-based problems and problems with limited 
transaction processing but which require considerable number 
crunching power do not create a conducive environment for 
rapid iteration. Many of the Army's STAMMIS are batch 
systems. This is probably due more to prior hardware 
constraints and when the MIS were developed rather than a 
blanket statement that the Army prefers batch MIS to 
on-line systems. User and management needs would be better 
served inmost cases if they were on-line or real time 


systems. 
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A big question, then, is whether prototyping is 
appropriate for STAMMIS development. Management information 
systems tend to deal with structured problems. Based on his 
experience at American Telephone and Telegraph (AT&T), Boar 


sums up prototyping candidates this way: 


Prototyping works best. for on-line transaction 
processing oriented applications. The application 
should be a structured problem with a ES amount o 
data elements and record rela ES ut `a small 
amount of algorithm processes. Ref. 45: p. 64] 


Nearly all STAMMIS meet these criteria. 

Given the two views of prototyping discussed earlier, 
which view of prototyping is appropriate for ISEC? Perhaps 
both are appropriate. The throwaway prototype is applicable 
to STAMMIS projects that, for whatever reason, must be 
contracted out. The skeleton system developed during the 
prototyping process can be used as a requirements document. 
It may also be an appropriate view for a STAMMIS which 
requires a degree of efficiency that current fourth 
generation languages do not provide. In both cases, the 
prototype serves as a requirements/specification document. 

The evolutionary or iterative approach iS appropriate 
for most STAMMIS developed in-house at ISEC, regardless of 
application size. Some literature on prototyping suggests 
that it will only Support small systems development. 
[Ref. 49: p. ID/9] This may have been true in 1978 but there 
is evidence that this is no longer true today. Boar 


contends that: 


Given the state of software Pa or oe today, there is 
no reason why the techniques described in this book 
cannot be used. to build rapid prototypes of medium and 
: applications as well as simple ones [Ref. 
P- : 
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ISEC has done some recent experimenting with 


prototyping. The ASD assigned to support the Logistics 
Center at Ft Lee, Virginia, has successfully built two 
logistics systems using an incremental development 
strategy.’ Their successes are a testimony that prototyping 


works. The initial test system, the Standard Army Retail 
Supply System (SARSS), was created using a technique known 
by the acronym STEP-UP (Systems Through an Evolutionary 
Process Using Prototyping). SARSS was no trivial project. 


Yet in only four months, they had designed, developed, and 


tested a system of nearly 175,000 lines of code. SARSS was 
then demonstrated to users and, through user feedback, 
on-the-spot improvements and enhancements were made. ISEC 


estimated that the system will be fielded in two years (from 
project initiation) compared with the average track record 
of 5 to 7 years. 

SARSS was a bold step for ISEC. To attempt such a 
venture meant largely ignoring normal Army and DOD system 
development policies. The other success story is the Unit 
Level Logistics System (ULLS). Two more systems are being 
prototyped and are scheduled for fielding within the next 
year. All of these systems are interactive systems 
employing the latest microcomputer technology. They can be 
run from menus or with a command language thus supporting 
both beginner and experienced users. They also feature 
extensive "help" facilities. [Ref. 50: pp. l-14] 

Why were these systems successful? There are several 


reasons; they are listed below. 


'The. ISEC. ASD that e logistics systems is 
Y collocated with e FP. in the same building. 
his is not true of the ASDs that support personnel and 
financial systems. This author believes that it was a 
fundamental reason why the two projects succeeded. 
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l. The physical collocation of the FP and ASD helped 
foster a team attitude and facilitated problem 
solving, and communication problems. The "We - They 
Syndrome" was eliminated. 

2. Good management and software engineering techniques 
were employed. Careful planning and quality 
assurance activities such as walkthroughs and testing 
at multiple levels, a "murder board" and change 
control techniques were conducted. 

3. The users were an integral part of the process. User 
feedback was sought at various phases and their 
contributions in terms of improvements and 
enhancements were significant. 


4. Prototyping represented a new challenge to the ASD 


supporting logistical systems. It was exciting to 
work with an innovative software development 
methodology. This challenge and excitement led to 


employee enthusiasm and internally-driven motivation. 


There are some things that must be changed if ISEC is to 
see long range benefits from prototyping or evolutionary 
development. A major problem for the developers at Fort Lee 
was the lack of an integrated software tool set to 
facilitate STAMMIS development. The tools (TAPS and TAPS 
II) provided by ESEC S Executive Systems Software 
Directorate (ESSD) are not adequate. In fact, the primary 
tool used to develop SARSS and ULLS was written in-house at 
TSEC . More will be discussed about the need for an 
integrated tool set in chapter 5. 

A second potential problem is the ASD's conscious 
decision that documentation is not an integral part of the 
evolutionary development process. To adopt such a 
philosophy is to ignore what history has taught us. 


Programs that are not documented are more difficult to 
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understand and therefore maintain. Without documentation, 
increased maintenance costs may offset the shorter 
development time that evolutionary development offers. The 
positive side of this issue is that an integrated software 


tool set automates much of the documenting process. 


G. PROTOTYPING AND EVOLUTIONARY DEVEOPMENT: THE BOTTOM 
LINE 


Traditional analysis methodologies have not adequately 
come to terms with three overriding and persistent problems 
of requirements definition. These problems are: 

l. Users have extensive difficulties prespecifying final 
and ultimate requirements; 

2. Descriptive and graphic analysis techniques are 
inadequate to portray the dynamics of an application; 
and 

3. Poor communication is an inherent and debilitating 
problem among the developer participants. 

Well-intentioned efforts to systemize and discipline the 
process have not solved these problems. 

The solution is the evolutionary development of systems 
by the building and refinement of models. Recent 
improvements in software tools and fourth generation 
languages have made evolutionary development both feasible 
and practical. Evolutionary development should become a key 
definition strategy for STAMMIS because of the advantages it 
offers. While not appropriate for all situations, it isa 
high productivity methodology for solving the requirements 
definition problem.*? [Ref. 45: pp. 206-207] 


EE S es would complain that o ae and 
Se eon development are different methodo les and 
Should not be "lumped together. While it may pe rue that 
a are different” methodologies, they both are similar and 
useful „techniques for solving the ido problems 
that cripple so many software efforts: 
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V. THE SOFTWARE DEVELOPMENT ENVIRONMENT 


A. INTRODUCTION 


Several authors hold a rather narrow view of the 
software development environment taking it to mean a kind of 
development system. This author takes a broader view, one 


Similar to Capers Jones: 


e Hee ramming. environment consists of the sum of the 

A facilities tools social structures, and 

ellectual skills dedicated_to Ss pucca and 
Me tenance by an enterprise [Ref. 


The physical facilities include such things as office space, 
small conference rooms for team meetings, and technical 
libraries. Tools refer to both the hardware and software to 
Support programmers and analysts. Social structures are the 
formal and informal relationships within an organization. 
(Organizational policies and programs shape many of the 
formal and informal structures within an organization. Some 
of these policies and programs will be discussed in lieu of 
issues such as the pros and cons of matrix organizations 
versus functional organizations. ) The intellectual skills 
includes the initial skills employees have when hired and 
the additional training they receive on the job and in the 
classroom. 


This chapter will evaluate the programming environment 


AIESEC. A major portion of the chapter will be dedicated 
to tools which support the programming effort. The 
investment in the right tools (assuming proper training and 
use) should provide significant productivity gains. The 
other environmental factors will be covered, but in less 
detail. Nevertheless, they are important and must not be 
ignored. 


he: 


B. THE PHYSICAL ENVIRONMENT 


The physical environment plays a major role in employee 
motivation, loyalty, and productivity. Many managers assert 
that people are their most precious asset. If this is true, 
then employee's work areas should be planned with 
psychological and physical comforts in mind. This will help 
eliminate such problems as fatigue, eye strain, and 
backaches. The proper environment can also improve 
motivation, increase self-esteem, lessen anxiety levels, and 
improve concentration. [Ref. 51: pp. 18-19] 

The physical environment at ISEC is typical of 
government office buildings. The facilities were not 
designed around the specific needs of computer programmers; 
they were designed for administrative functions. Common 
complaints at ISEC center on the lack of space, lack E 
terminals, lack of small rooms for team meetings and 
walkthroughs, and a temperamental climate control (heating 
and air conditioning) system. The facilities at ISEC bear 
little resemblance to IBM's Santa Teresa Laboratory in San 
Jose, California, which was designed for programming 
development. 

There is no firm agreement as to what constitutes a good 
physical work space. Opinions offered are highly 
subjective. [Ref. 52: p. 335] Nevertheless, the design 
criteria for the Santa Teresa facility might serve as a 
model or target for which ISEC can aim. Table X presents 
IBM's primary building and programmer design considerations 
at the Santa Teresa Laboratory. [Ref. 53: pp. 4-25] 

ISEC's present facilities do not measure up well against 
the industry standard of 90-100 square feet of floor space 
per employee. Programming requires different types of 
office space and furnishings than purely administrative 


functions. The computer printout listings and computer 
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TABLE X 
THE PHYSICAL PROGRAMMER ENVIRONMENT - IBM 


BUILDING REQUIREMENTS 


e Outside awareness is essential for as many 
offices as possible. Natural lighting is highly 
desirable for all work areas. 


e Emphasis should be placed on_ sound proofing, 
particularly between adjacent offices. 


e Maximum ON is desired for placement and 
use of computer erminals and associated work 
Space. 


e The site and, in particular, the data processing 
and project buildings must be secure. 


PROGRAMMER REQUIREMENTS 


e Communication. The primary consideration in 
eS ening e offices is ease of communication. 
Team members will have to be able to communicate 
within programming teams, with other teams on the 
same project, and with other teams world-wide. 


e Privacy. Each individual will require a personal 
work area with an environment that supports the 
intensive concentration needed for hig del 
problem solving. | Acoustical isolation, adequate 
ventilation, and individual control of the office 
environment are key design considerations. 


e Furniture. Office furniture and fixtures should 
be effective for many different tasks. The 


rogrammer's basic document is a a 
Fantold program listing which opens to 15 b 
inches. Work surfaces that can accommodate 
several listings a taneously, and lockable 
storage that can accommodate these documents in 
hanging vertical files, are required. 


e Computer Connections. Every office must have 
connections to accēss the computer via_ video 
terminals. Preferably, each programmer will have 


their own terminal. 
° ME CARO NO Ea Design flexibility should be main- 


ained with regard to current and future program- 
ming technology. 


reference manuals consume considerable work and storage 


Space. The programmer needs a desk for manual work, a work 
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table to spread out listings or notes, a terminal for 


interaction with the computer, and appropriate storage 
areas. All this should be encapsulated in a comfortable 
work environment with adequate lighting, heating, air 


conditioning, and ventilation. The programming team concept 
used in large software projects mandates a requirement for 
small and large conference rooms. These are used for team 
meetings, walkthroughs, and formal reviews. ISEC is aware 
of their space constraints and are looking at steps to 
remedy the situation. The major space problems may be 
alleviated if ISEC is able to lease additional space in 
their office building in Falls Church, Virginia (the Melpar 
Building). 

An important question to consider is "how much will 
productivity increase if we spend X thousand dollars on 
improvements to the physical environment?" Unfortunately, 
there are few if any valid, specific studies relating to 
programming environments. IBM estimates an 11% improvement 
in productivity at Santa Teresa. They admit that it is 
nearly impossible to Separate gains based on the physical 
environment and gains based on other factors (e.g. process 
and technology changes). [Ref. 13: p. 310] 

Hertzberg's two-factor motivational model suggests that 


physical facilities satisfy the hygiene or maintenance 


needs. This does not mean that upgrading the physical 
facilities will not yield increases in productivity, 
efficiency or creativity. Research has shown, though, any 


increased motivation due to better working conditions may 
not be as permanent as when the source of someone's 
motivation is the task itself. [Ref. 54: pp. 12-13] On the 
other hand, a poor working environment has a negative impact 
on employee morale, absenteeism, turnover, and productivity. 
To what degree is very difficult to predict or measure. A 


Survey conducted by Jac Fitz-enz in 1977 revealed that data 
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processing professionals regard working conditions as less 
important than employees in other professions. [Ref. 55: p. 
126] 


C. THE STRUCTURAL ENVIRONMENT 


im otaffing 


There is considerable evidence that suggests some 
programmers are more than an order of magnitude more 
productive than other programmers. [Ref. 56: p. 846] This 
implies that management should seek to get these "super 
programmers’ rather than programmers on the low end of the 
Spectrum. ISEC has not attracted this sort of top talent in 
the past which suggests they can do more in this regard. As 
a minimum, they can screen potential employees before they 
enter the intern training program. There are tests 
available that can be useful for this purpose. 

Boehm suggests some staffing principles for software 
development; Table XI is a summary of his major points. 
[Ref. 29: pp. 667-672] The principles of job matching and 
career progression require some discussion. They sound 
straight-forward and logical but are often not practiced. 
Some people are placed in a job (e.g. VTAADS maintenance 
programmer) where they become "irreplaceable" so they get 
stuck there forever. Other people rise to positions where 


their technical skills become obsolete after a few years. 


[Ref. 29: pp. 668-9] Given the rapid evolution in the 
computer field, we must provide opportunities for employees 
to grow with the field. The message for management is to 


keep people motivated by providing an atmosphere where they 
can fulfil their needs. 

Research by Couger and Zawacki has indicated data 
processing professionals exhibit different motivational 


tendencies than other workers. In particular, they have a 
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TABLE XI 
STAFFING PRINCIPLES - BOEHM 


Use Better and Fewer People 


The_ bulk of productivity comes from a relatively 
small number of participants. 


The Principle of Job Matching 


Fit the task to the skills and motivation of the 
people available. 


The Principle of Career Progression 


An organization does best in othe long-run by 
helping its people self actualize. 


The Principle of Team Balance 


Select people who will complement and harmonize 
with each other. 


The Principle of Phaseout 


Keeping a misfit onthe team does not help 
anyone. 





higher growth need and lower social need than workers in 
other professions. [Ret I/O 126] The Fitz-enz study 
Showed that the age and sex of individual programmers and 
analysts affects how they are motivated. [Ref. 55: p. 127] 
The lesson for management from this is that they need to 
learn what motivates their employees to increase 


Productivity. 


With personnel _budgets representing an ever-increasing 
ortion of the DP budget, every manager should strive to 
elp. the DP staff perform to he best of their 

abilities. A persistent effort by management can turn 

motivation from „a meaningless buzzword into a valuable 


tool for improving productivity and reducing turnover. 
[Ref. 68: p. 9] 
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2. Awards and Incentives 


Various authors have shown that, under the right 
circumstances, reward systems can contribute to greater 
employee productivity. Based on the author's on-site visit, 
this avenue has not explored in any detail at ISEC. One 


method worth considering is a productivity-based reward 


system. It is a form of performance bonus system which tie 
employee earnings to their output. The intent is to 
motivate employees to produce at an optimum level. A 1980 
General Accounting Office (GAO) report states that 


productivity-based reward systems should not be used in all 
situations. The report provides the following suggested 


general principles: 


l. Performance should be judged by objective measurable 
eee ection standards that include all important aspects 
O e job. 


2. The reward offered should be of value to the 
employee and be significant enough to stimulate effort. 


3. The connection between exceeding. the roduction 
standards and receiving the reward should be clear, and 
employees should understand the plan. 


4. The plan must be accepted 
Ref. 


by OYE ES and fairly 
applied by management. pS] 
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The report further states that when the above principles 
cannot be applied, organizations should not attempt to use 
bonus pay as an incentive for productivity gains. The 
Office of Personnel Management was to have drafted guidance 
addressing the design, implementation, and management of a 
productivity-based reward system. ISEC should attempt to 
obtain that guidance. 

David Sumanth, author of Productivity Engineering 
And Management, provides a whole chapter on employee-based 


productivity improvement techniques. One of the techniques 


A? 


is a group incentive plan called Improshare.? Sumanth gives 
a detailed 3-page explanation of how the plan works (See 
Sumanth, pages 405-407). Suffice to say, Improshare is 
designed to share productivity gains between employees and 
management. No attempt is made to determine the source of 
the productivity gains or the extent to which each worker 
contributes. It operates on the premise that workers and 
management will be interested in improving productivity when 
both gain something from the increase. [Ref. 22: pp. 
405-407] Sumanth offers some other individual and group 
incentive plans that ISEC may wish to explore (See Sumanth, 
pages 394-429). 

Motivating employees is a management obligation. 
Seeking new and better ideas to motivate employees to higher 
levels should be a constant effort. Recognition of 
outstanding employee efforts is a must for any manager. 
Awards must be timely and commensurate with the performance. 
Equally important, but often overlooked, are the day-to-day 
"strokes" and "pats on the back" which employees deserve for 
successfully completing assignments and for just "doing 
their job." Research has indicated that recognition for 
work completed is perceived as very important to employees. 
We must never forget that people have feelings; they need to 


feel wanted and appreciated. 


ae Suggestion Programs 


Don't all government agencies have suggestion 
programs? The answer is most have a program, at least in 
name. But many programs are not active programs. Having a 


suggestion box up in a few locations can hardly be construed 


as a bonafide active suggestion program. There are two 


. “Improshare is a Registered Service Mark of Mitchell 
A and is derived from "Improved Productivity Through 
aring. 
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related techniques which are particularly helpful obtaining 
and implementing employee ideas. One method involves the 
establishment of groups of employees who voluntarily 
cooperate to solve problems related to all facets of a job. 
These are known as quality circles. They evolved from 
Japanese management practices and have received considerable 
press in the last several years. Still, they have been 
overlooked by most federal agencies. 

The second technique iS an extension of quality 
circles called PQ teams. Sumanth coined the term which 
stands for Productivity and Quality teams. The 
distinguishing factor between PQ teams and quality circles 
is that PQ teams are smaller and more functionally specific. 
Usually a supervisor serves as a team leader to preserve the 
present authority structure. Also, the group size is 
normally less than 10 members. [Ref. 22: pp. 421-422] Table 
XII is a summary of benefits from a PQ team program. 


Sumanth contends that: 


PQ teams are an effective means of improving employee 


morale, quality, and productivity in an organization. 
They have one eet purpose in mind: To surface the 
talents of individuals working in the organization to 


the maximum extent possible by providing the specialized 
gi ining and management support necessary to accomplish 
ENIS. 


Team Spirit, POSE Eve thinking, and the a OF 
achieving excellence are three important characteristics 
of PQTs, making them not only efficient in peo nE 
improvements in morale, communication, ‚loyalty, 
Productivity, and quality., but also making them 
effective in achieving organizational goals. Ref. 22: 
p. 


4. Flextime 


Flextime has been a mixed blessing for ISEC. 
Flextime allows employees to avoid the Washington D.C. 


rush-hour traffic and take advantage of their "biological 
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TABLE XII 
BENEFITS OF PQ TEAMS - SUMANTH 


ORGANIZATIONAL BENEFITS 


e Improved. product quality and/or service 
reliability. 


. © Greater customer satisfaction. 
e Reduced costs of operation. 
e Greater employee stability. 


e More enthusiasm and involvement from employees 
and management. 


e Increased: loyalty and commitment to the 
organızation. 


* Management can spend more time training employees 
rather than ordering them. 


e Improved productivity of operations. 


EMPLOYEE BENEFITS 
e Greater job security. 
e Improved self-image of employees. 


e Improved work environment. 


clocks." It means employees on flextime arrive fresh rather 
than tense and "stressed-out." Nevertheless, flextime is 
only productive if the employees who arrive early (or stay 
late) make productive use of their time. Managers and 
programmer team leaders hinted that a good number of 
flextime employees (20-40%) were not using their 
"unsupervised hours" efficiently. Reading the newspaper, 
exchanging the latest gossip, and soaking up several cups of 
coffee were some typical activities cited by management 


which are non-productive. 
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The best way to approach this problem may be simply 
the installation of a uniformly applied productivity 
measurement system and good leadership techniques. Flextime 
1s a valuable program which has several benefits. 
Cancelling the program is not recommended; doing so would 


create bigger problems. 


D. DEVELOPMENT AND MAINTENANCE TOOLS 
l1. Hardware Considerations 
a. Execution Time and Main Storage Constraints 


Boehm provides some figures in his book Software 
Engineering Economics that indicate the procurement of 
additional computer speed and storage can lead io 
significant overall systems cost savings. This may be 
somewhat counter-intuitive but excess capacity can actually 


save money in the long-run. Boehm says: 


Software productivity can be improved considerably by 

acquiring enough computer speed and main storage 

capacity to free the software development from, the 

excess effort required to shoehorn the’ software within 

Feet ape Loe time and main storage constraints. 
ef. Ep: 


He also provides the following advice: 


l Overall system cost is. generalii: minimized by 
m curing computer hardware with 30 to 50% more capacity 
han is absolutely necessary. 


2. The more the ratio of software-to-hardware cost 
increases, the more excess capacity one should procure. 


3. It is far more e to err by procuring too little 
hardware capacity than by procuring too much. aes is 
especially important, given the tendencies ..... for 
Sizing estimates to be low and for software products to 
expand during development and maintenance. Thus, the 
preferred amount of hardware capacity procured should be 
even higher than the minimum system cost level. 
[Ref. 29: p. 663] 
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This should become less cof a problem as the hardware cost/ 


performance ratio and storage costs continue to fall. 
b. Computer Turnaround Time 


The personnel systems and some financial systems 
STAMMIS are developed and maintained on an IBM 3033 (at the 
Melpar Building) and on an Amdahl 580 (located at the 
Vertical Integrated Automation BaseLinE (VIABLE) Regional 
Data Center (RDC) in Newington, Virginia). There have been 
complaints that the turnaround time for development and 


maintenance work is next day service or 24 hours in some 


cases. This is little better than batch processing. 
Although measures have been taken to correct this, the 
programmers and managers still perceive a problem. The 


procurement of an IBM 3081 at the Melpar Building is 
underway and may relieve the log jam. 

A study was conducted by Major Washburn during a 
two week individual mobilization assignment annual training 
period in July, 1984. Washburn suggested that use of 
micro-to-mainframe hookups to help reduce the turnaround 
time problem.’° His idea was to off-load work from the 
mainframe to some type of programmer work station. Little 
followup action has been done on Major Washburn's 
Suggestion. This is a sign that the day-to-day workload is 
so heavy that management does not have time for long-range 
planning or productivity improvement. Because of the heavy 
workload, ISEC may want to commission some bright Army 
graduate school attendees to do thesis research in this 
area. Specifically, the students could conduct a problem 


analysis and feasibility study which addresses potential 


A good source of information on this topic is a book 
Delen The Micro-Mainframe Link, published by John Wiley & 
ons, INE Aeee 
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alternatives and a recommended course of action for ISEC 
management. 

Since Major Washburn's study, there has been 
some improvement in the products which link mainframe and 
microcomputers. Many of the products are based on the work 
Station concept. General Dynamics, a leading government 
contractor, claims to have increased their productivity by 
30% using VS COBOL Workbench by Micro Focus, Inc. (of Palo 
ieee California). (Their stated productivity goal was 
DO.) To obtain their system, General Dynamics used a 
competitive bid process in which the VS COBOL Workbench was 
chosen from several bidder's products. It runs on IBM AT 
and IBM PC/XT hardware which are the type of microcomputers 
that ISEC has. [Ref. 60: pp. 34-35] 


2. Software Tools 
a. Introduction 


Software tools can radically change and improve 
the entire software development and maintenance process. A 
software tool iS a computer program designed to automate 
Some portion of the software development and maintenance 
process. The development tool set should support both 
management and programmers. Larger software projects 
usually require a larger proportional period of time and 
effort for management functions and documentation. In fact, 
actual coding represents only 15-304 of the total effort on 
large systems. The remaining time is spent planning, 
coordinating, communicating, reviewing, testing, and 
documenting the system. 

A 1983 GAO report criticized government agencies 
for not using software tools during the testing process. 
Their study revealed that only 13% of the installations 


surveyed used tools for software testing. [Ref. 6l: pp. 
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12-14] While the GAO study examined only testing, there are 


many indications that tools are neglected as productivity 


aides throughout the entire process. A 1984 study of 25 
software development environments in the US and Japan 
surprisingly revealed industry uses software tools 
Sparingly. [Ref. 62: p. 59] Rudy Bazelmans summarized the 


reasons as follows: 


1) The hardware engineering background of most managers 


causes them to (be unsympathetic to the need for 
software ~ tools, Mos corporations _ lack an 
organization whose charter is to evaluate, select and 
develop tools, .3) The lack of reuse of tools, 4 The 
abundance of incomplete or poorly documented oo lise 
[Ref. 63: p. 65] 

b. Software Tools - Desirable Features 


There are hundreds of software tools available 
on the market today. Many are fine products, others less 
SO. The tools include text editors, linkers, static 
analyzers, office automation packages, statistical packages, 
program management packages, data base management systems, 
cross-compilers, Simulators, emulators, test data 
generators, test coverage analyzers, application generators, 
and many others. William Howden provides some insight into 
the types (and cost) of tools necessary to support large 
projects such as those ISEC develops. He suggests that the 
system be built around a software engineering data base 
which has a version control and automated project control 
capability. Such a tool system would support all phases of 
the software life cycle from requirements definition and 
design to testing and documentation development. [Ref. 64: 
pp. 321-325] Several authors say that a development software 
tool set should be able to support these functional areas: 


Us Prototyping: 
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Project management and budgeting; 
Program coding and debugging; 


Program testing; 


wm + Ww N 


Data base development; and 
6. Automatic generation of development documentation. 

To support prototyping, the software tools should be inte- 
grated with an active data dictionary. The software and the 
developer work through the data dictionary so that it main- 
tains a current snapshot or model of the system. [Ref. 45: 
pp. 118-119] A data base management system (.e.g. Applied 
Data Research's (ADR) Datacom/DB) to facilitate prototyping 
and programming functions is very useful. A fourth genera- 
tion language capability to support prototyping (e.g. ADR's 
Ideal) is recommended. 

Three features are very important in tool 
procurement. The tools should be compatible - that is, they 
Should be able to communicate with one another without 
difficulty. They should be easy to use. Tools that are not 
understood by the programmers will be "left on the self.” 
Tools should support the entire software life cycle. The 
real key to productivity is automating as much of the 


process as possible. 
C. USE.IT - A New Approach to Systems Development 


Most people would agree that automation of the 
software development process would dramatically increase 
productivity. Further, if the process could be based on 
provably correct constructs, testing, system checkout, and 
maintenance would be sliced to a mere fraction of the effort 
they now consume. Margret Hamilton and Saydean Zeldin have 
combined these two features into an integrated family of 
tools supporting the system life cycle. It is called 
USE. IT. 
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One could argue that USE.IT is actually a 
totally different methodology to approach systems 
development and does not belong in a section on software 
tools. The counter argument would be that the basic 
methodology is the same, only the tools are different. 
Regardless of where it should be discussed, the concepts 
behind USE.IT are intriguing. The coeditors of The Journal 
of Systems and Software had this to say: 


Hamilton and Zeldin's paper on, the USE.IT system should 
be. considered must reading by. all concerned with 
software development. Their "worki . has now 
matured into what James Martin has hailed as the first 
complete Sy Sem of tools which can result in provabill 
correct software. It would be surprising, however, i 
the paper did not evoke controversy among software 
professionals. [Ref. 65: p. 1] 


The paper the coeditors refer to is entitled "The Functional 


Life Cycle Model and Its Automation: USE.IT." One of the 
coeditors is Major General Alan B. Salisbury, ISEC 
Commander! Below is a brief summary of how USE.IT works. 


The first step is to define the requirements. 
USE.IT has a requirements definition language called AXES. 
AXES helps users define requirements with either statements 
or a graphics mode. (AXES is based on Higher Order Software 
(HOS) Theory which is described in detail in James Martin's 
text Systems Design From Provably Correct Constructs.) 
[Ref. 2: pp. 37-143] AXES defines systems from three basic 
mechanisms: data types, functions, and structures. Axes is 
not a pure programming language; nor is it a software 
specification language. It is nonprocedural and can be used 
to specify systems other than software (e.g. hardware or 
people systems). [Ref. 36: pp. 40-41] 

The next step once the requirements have been 
defined with AXES is to check the requirements for 


ambiguity, consistency and completeness. The Analyzer 
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component of USE.IT performs this task. After any problems 
identified by the Analyzer are resolved, the requirements 
are consistent and complete. [Ref. 36: p. 41] 

The third step is performed by the Resource 
Allecation Tool (RAT). From the analyzed AXES 
specification, the RAT produces code automatically. The RAT 
will even produce documented code if asked to do so. 
(Additionally, the AXES front end produces a documented 
hierarchy of the requirements for the user.) The power and 
flexibility of the RAT are impressive. [Ref. 36: pp. 41-44] 


The RAT provides the end-user with the capability to 
reconfigure to any language or machine environment 


desired, whenever. desired, _. without modifying the 
requirements definition., Since the Analyzer has 
guaranteed that the requirements used by the RAT are 
consistent, the automatic programs produced by the RAT 
are also consistent. ot only are the initial 
requirements dermed e oy che nus ere ua ranteed to be 
interface error free after the es hase of 
development, they are also guaranteed_ to be he same 
ones the user defined. [Ref. 36: p. 4 


Another useful feature of the RAT is: 


The same set of requirements that has been "ratted" to 
one environment FORTRAN) can be ratted to another 
environment (e.g. da). This means, for example, that 
developers who are anxious to start to use the Ada DOD 
standard language but who do not have the compiler and 
other support tools yet available can define their 
requirements in AXES and rat them to FORTRAN or to some 
other HOL environment until Ada is available. They can 
Seu ty rat them to Ada when Ada is ready. It also means 
that developed systems are never obsolete just because 
there is a new language or. a new computes system 
introduced within an organization. (Ref. 36: p ASÍ] 


The final step includes compilation followed by 
execution. This is done on what Hamilton and Zeldin call a 
Higher Order Machine (HOM) which executes the "ratted" 
requirements. The whole process sounds like a dream come 


true. Table XIII is a summary of the USE.IT benefits. 
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TABLE XIII 
BENEFITS OF THE USE: ITTI TOOLS SEEN 


Interface errors are found, automatically before 
implementation and are eliminated. 


Requirements are complete, consistent and 
unambiguous. 


Programming is automatic. 


The majorit of the documentation can be 


generated atona c e 


Functional integrit of the requirements is 
maintained after implementation. 


A means to achieve reuseable software is 
provided. 


Different requirements definition languages and 
techniques can be integrated. 


Cost savings of up to 75% can be expected over 
traditional methods. 


Specifications are easier to modify than with 
most other techniques. 





The predominate use of USE.IT is for designing 


complex systems. James Martin speculates why: 
Most complex specifications are inadequate. The human 
mind simply cannot spot the ambiguities, 
inconsistencies, and incompleteness in highly complex 
specifications. And. a team of human minds 1S_ worse 
because they create pieces that do not mesh exactly. A 


tool for creating compilable specifications enforces 
completeness, consistency, and lack of ambiguity in the 
specifications; otherwise, it cannot generate code for 
n kan. 2) | 


Martin also says that USE.IT does not eliminate errors in 
the concept of what a program should do; we can tell it to 
do something stupid and the methodology can create provably 


correct code for that stupid function. 
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USE.IT has been successfully used for large 
applications. Substantial Savings were documented. 
Hamilton and Zeldin conclude that with USE.IT, an estimated 
minimum cost savings of 50% results. Perhaps more 
important, users get what they want because unambiguous 
requirements definition and rapid prototyping are part of 


the process. 
d. Software Tools at ISEC 


The Executive Systems Software Directorate 
(ESSD) tests and procures software tools for ISEC. The 
programming directorates have the impression that ESSD could 
improve the support they provide. Tools such as TAPS are 
1960s vintage and are no where near state-of-the-art. Rudy 
Bazelmans published a recent article entitled "Productivity 
- The Role of the Tools Group.” [Ref. 63: pp. 63-75] He 
discusses issues which are pertinent to ESSD such as 
activities the tools group can do to help the programmers. 

A significant problem facing ESSD is’ the long 
lead time required to evaluate and procure perspective 
software tools. The economic justification for government 
procurement iS a laborious drill involving many layers of 
approval. A recommended approach to procuring a unified, 
integrated tool system is to follow the pattern the Army 
used on the VIABLE contract. The focus should be on the 
functions the system must provide rather than on a specific 
list of hardware and software to accomplish the functions. 
The system itself should be modular and expandable. A local 
area network type technology facilitates modular expansion. 
Once a procurement document is in place, it can be used as a 
vehicle for future tool system upgrades; the need for 
re-justification of upgrades should be eliminated. 
[Ref. 27: pp. 22-26] 
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In preparing the economic justification for the 
development tools system, trying to assess how users will 
use the system is a problem. Determining requirements is no 
easy task. It will take several months for the programmers 
to be trained and feel comfortable with the system. Once 
the become comfortable with the tool system, they will use 
it in ways that are difficult to anticipate. [Ref. 27: pp. 
25-26] 


E. THE "INTELLECTUAL SKILLS” ENVIRONMENT 


The training program at ISEC is commendable. The 
courses offered in the continuing education program are 
particularly outstanding; unless employees attend them, 
however, they are worthless. Managers and programmer team 
chiefs must encourage their workers to use this excellent 
program. They must plan and schedule their employees for 
appropriate courses. Sending subordinates to training is 
important for several reasons. Among them are: (1) meeting 
the high growth needs of DP professionals; CZ) keeping 
current with the latest techniques and technologies; (3) 
increasing long-run productivity; (4) serving as a reward 
for hard work or a break from the normal routine; and (5) 
serving as marketing technique to attract new employees. 


Managers should also attend certain classes to maintain (or 


obtain) technical proficiency. The short-run productivity 
decrease should be offset by increased long-run 
prodüctivity. 


The intern training program at ISEC has been important 
to the very survival of ISEC. Without it, ISEC's main 
source of new programmers and analysts would slow to a 
trickle. Although the intern training program is good, 
there is some room for improvement. Four criticisms of the 


program were raised by ISEC employees: 
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Entry screening into the program is too lax; 
Poor performers in the program are not weeded out; 


Software testing is not given adequate attention; and 


fF WH Pp 


There is little "hands on" training with software 


tools. 
These are definite shortcomings. The first two points 
require management attention. Weak performers are a burden 


on an organization. Not every person has the mental problem 
solving abilities that programming requires. The intern 
program is a good test of one's abilities. Candidates who 
do not measure up should be phased out. It could be argued 
that the last two points are better saved for 
On-the-Job-Training (OJT). This assumes that programmer 
team chiefs are good teachers and will take the time to 
adequately train the intern graduates - a risky assumption. 
The author thinks testing and tools deserve some classroom 
time even if it means extending the program course length. 


They are just too important to be left to chance. 


F. SUMMARY 


This chapter has been a review of the total software 
development environment. It includes not only the physical 
working conditions and tools but also the formal and 
informal organizational relationships and the intellectual 
skills of the work force. The area requiring the most 
attention at ISEC is software tools. A unified set of tools 
that are easy to use, compatible (ability to communicate 


with each other), and which support the entire software life 


cycle is needed. The physical working conditions have 
considerable room for improvement. The training program at 
ISEC is sound but could use some fine tuning. The 


structural environment needs some management policy and 


procedure innovations. 
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The next chapter focuses on management issues. 
Management barriers to productivity and software contracts 
are discussed. Project planning techniques and a software 


productivity improvement program implementation plan are 


presented. The chapter also raises some other management 
issues such as the importance of staying "in touch. 
customers. 


94 


VI. SOFTWARE MANAGEMENT AND PRODUCTIVITY ISSUES 


A. INTRODUCTION 


Dramatic improvements in hardware and software 
capabilities during the past several years have steadily 
increased the complexity of systems development projects. 
Today's environment requires the close cooperation of 
technicians, specialists, users, analysts, and programmers. 


The key to the success of this cooperative effort is 


effective management procedures, policies, and practices. 
fact, of all the variables involved in software 
development, many experts believe that management is the 


most important. 
This chapter is not about how to manage software 
development and maintenance. There are many books and 


articles available for that purpose. The objectives of this 


chapter are to: (1) discuss some management barriers to 
productivity; (2) explain common software contract problems 
and their solutions; (3) discuss project planning systems; 


and (4) provide the framework for establishing an integrated 


software productivity improvement program at ISEC. 


B. GENERAL MANAGEMENT ISSUES 


l. Management Barriers to Productivity 


The productivity problem is complex - it is many 
smaller problems entangled in one large mess. Because it is 
a complex problem, simple quick-fix solutions are doomed to 


fail. Sumanth summed up the situation this way: 


Productivity improvement must not be E ES aS) a one 
shot project or Pe oer M It must be ea and 
continuous . . . Whether newspapers or T e the 
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productivity issue a headline story or not, «an 
organization must strive to have a E oe ee 
ef. : 


AS as a normal, routine function. p 
Below are seven of the major management barriers to 
productivity. 


a. Short-Run Blinders 


There is considerable pressure on all levels of 


management to look good today so that they can get a good 


report card based on their short-run results. Despite the 
lip service paid to the long-run, evaluations are tied to 
the short-run. Productivity improvements do not happen 
overnight. Frequently, improvements can decrease 
productivity in the short-run due to learning curve 
phenomena. Management must treat productivity as a long 
term investment. Historically, the biggest gains in 


productivity have been tied to technology and innovation. 
b. The "Desk-Bound and Meeting Syndrome" 


Managers tend to spend their time attending 
meetings, reading and writing staff reports and proposals, 


and reviewing computer printouts and mounds’ of paperwork. 


Unfortunately, the thing that gets neglected is the 
organization's greatest asset - their people. Productivity 
suffers because the employees feel ignored and 
unappreciated. 


Two authors in particular are strong advocates 
of "management by walking around" (MBWA). The term was 
coined by Tom Peters, co-author of the classic In Search of 
Excellence. He discusses the concept extensively in another 
book he co-authored entitled A Passion For Excellence. The 
other author who favors this management technique is Andrew 
Grove, president of Intel Corporation (of Santa Clara, 


California). Here is what Grove says about MBWA: 
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There is_an especially efficient way_to get information 
much neglected by most managers. matris to”. Visit a 
particular place in the company and observe what s goin 

on there. Why should you do this? Think of wha 

eeeens when somebod comes to see a manager in his 
office. . A certain stop-and-start dynamics occurs when 
the. visitor sits’ down, something socially dictated. 
While a two-minute kernel of information iS exchanged, 
the meeting often takes a half hour. But if a manager 
walks through an area and sees a person with whom he has 
a two minute concern, he can simply stop, cover it, and 
be on his way. Ditto for the subordinate when he 
initiates conversation. Accordingly, such visits are an 
extremely effective and. efficie way to transact 
managerial business. [Ref. : p. 49] 


Although the concept sounds like apple pie and motherhood, 
ISEC managers interviewed said they wanted to do more MBWA 
but just did not have the time. Employees interviewed 
agreed that they rarely saw mid and top level management 


“floating” in their work area. 
c. Unwillingness to Experiment 


Procrastination and constant delays for more 


research can hamper the initiative and productivity of 


employees. This is not to say "doing one's homework" is 
unimportant. It is as long as it does not snuff out 
enthusiasm and innovativeness. Peters tells us: 


The most important and visible o ie of the action 
bias in the excellent companies is their willingness to 
try things out, to experiment [Ref. 67: p. 134]. 


d. Ivory Palace Policies 


Most authors agree that procedures and standards 
are key components of the software development and 
maintenance effort. Nevertheless, some of them are better 
than others. All too often, these rules and policies are 
made by the people who sit in their ivory towers. The 


policy makers do not fully realize the impact on the field 
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because they have failed to go down "into the trenches” to 
find out how things really are done and what the real 
problems are. This suggests that there are too many layers 
in the organization which isolates top management and 


increases the communication gap. 
e. Lack of Incentives 


It is easy to talk about the virtues. and 


necessities of improved productivity. But without any 
incentives to establish the commitment for improving 
productivity, it is doubtful there will be much success. 


The management implications are best summed up in the words 
of Douglas McGregor "Commitment is a function of the rewards 
associated with the achievement." AS was mentioned in the 
last chapter, there are several possible individual and 
group incentive programs that can be used to stimulate 


commitment. 
f. Poor Management Training 


Many managers have either too little training or 
their training is too specialized. What organizations need 
are managers who are problem solvers, decision-makers, and 
team builders who can motivate and lead employees. If 
managers are trained, it is often narrowly focused on such 
areas as "structured technique number 1" or "operations 
research technique A." These may be important but not as 
important as providing adequate leadership and direction to 


employees. 
g. The "Not Enough Time Syndrome" 


Several authors suggest that managers will do 
everything they can to meet some deadline regardless of 
product quality. It seems there is always time to redo the 


project but never enough time to do it right the first time. 
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This was a problem that was raised during the author's visit 


and will be discussed subsequently. 
lose to the Customer 


The importance of being "close to the customer" in 
any organization cannot be overemphasized. We discussed 
this earlier in the chapter on prototyping but it deserves 
repeating here as a management issue. Peters and Waterman 
wrote a whole chapter in their book In Search Of Excellence 
describing the criticality of being “close to the customer." 
The chapter provides several examples of excellent companies 
going the extra mile for their customers even when it was 
not necessarily economical in the short-run. Top management 
in these companies has made the chain of command understand 


that service is their business. 


Whether or not they are fanatic in their service 


obsession as Frito, IBM, or Disney, the excellent 
companies all seem to have very_powerful Service themes 
that pervade the_institutions. In fact, one of the most 
Significant conclusions about the excellent companies is 
that, whether their basic business was metal binding 
high technology, |. or hamburgers, chey all define 
themselves as service businesses. Ref. 07: p. 168 


They do this by tailoring their compensation packages, award 
programs, and training programs so that employees remember 
how their bread is buttered. 


ISEC could learn something from these excellent 


companies even though ISEC is a non-profit support 
organization. The functional proponent is actually an ISEC 
customer. Establishing good working rapport can help 


eliminate problems such as the FP establishing unrealistic 


deadlines for projects. This author believes that, where 
possible, the FP and associated ASD should collocate. This 
would reduce communication problems and delays. Collocation 


fosters a sense of team work thus destroying the "We-They 


Syndrome." 
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Collocation has been very successful at Fort Lee. 
One of the most noticeable things during this author's 
on-site visit was the excellent working relationship that 
the logistics systems ASD shared with their FP at the 
Logistics Center (Fort Lee). This was not the case for the 
other ASDs. The relationship between the FP and ASD affects 
performance and employee attitudes about their jobs. 
Because people's motivation plays a significant role in 
software development, collocation should be carefully 
considered as a way to increase productivity. It at least 
deserves further study. 

Collocation would entail having the ASD that 
supports financial systems move to Fort Benjamin Harrison, 
Indiana. It would also mean that the ASD that supports 
personnel and force accounting would move to the Military 
Personnel Center (MILPERCEN) in Alexandria, Virginia (or 
possibly the Pentagon). The benefits of such a move would 
have to contrasted with the moving costs. Questions of 
available space and computer resources need to be addressed. 

"Close to the customer" is important in more direct 
sense as well. Working closely with users in the field is 
absolutely critical to obtaining complete and accurate 
Specifications when developing new systems. Users help test 
the system and provide valuable feedback for additional 
features and corrections. This, in turn, helps reduce total 
life cycle costs by reducing future maintenance costs, the 
largest cost driver in most systems. Auerbach Information 


Management Series provides some additional insight below: 


Organizations have found. that the most successful 
systems are developed with a high degree of user 
interaction during he design phase. Online systems, 


for example, which depend heavily on efficient user 
interactions, are most effective when the user specifies 
screen designs and functions while the project team 
advises and performs the technical tasks. 


User involvement should be greatest during the initial 
phases of a development effort, when the systems 
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requirements are defined in general and in detail. If 
the user “buys in’ at this point, the PUES: s chance 
for success 1s greatly enhanced. [Ref. 58: pp. 2-3 


3. System Quality and Productivity 


Smart data processing managers are aware that system 
quality and high productivity are inextricably linked. This 
may be somewhat counter-intuitive; the effort necessary to 
achieve quality may lead one to the opposite conclusion. 
[Ref. 69: pp. 107-108] Generally, the payoffs for "doing it 
right the first time” are worth the added effort and 
resources in the long-run. [Ref. 70: p. 115] Recall that 
errors found during the maintenance phase are several times 
more expensive to correct than errors found during design. 

During the author's visit to ISEC 5-9 June 1985, 
several programmers and managers were asked: "Given the 
choice between meeting a deadline with an inferior product 
or requesting an extension and presenting a polished 
product, what would ISEC normally chose?" Most people 
interviewed felt top management would meet the deadline, 
although some felt this tendency might be changing. The 
latter is at least encouraging. It does point out a problem 
that is persistent in many military organizations. Managers 
tend to take a short-run view of productivity rather than a 
"We're in this for the long haul" perspective. Quality does 
not always get the attention it deserves. This was the "No 
Enough Time Syndrome" mentioned previously in the chapter. 
Only conscious effort and dedication will turn this 
situation around. 

ISEC is not unlike other government agencies in this 
regard. Two General Accounting Office (GAO) reports support 
this. The first, entitled "Federal Agencies' Maintenance Of 


Computer Programs: Expensive and Undermanaged," explains 
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problems and guidelines for software maintenance. [Ref. 71: 
pp. 1-24] The thesis of the second report, entitled "Greater 
Emphasis On Testing Needed To Make Computer Software More 
Reliable And Less Costly," is that agencies pay lip service 
to testing but fail to manage the software testing process. 
The result is costly, unreliable software. [Ref. 61: pp. 
5-14] Both reports are well written and are as applicable 
today as when they were drafted. ISEC would do well to read 
these reports and followup on the GAO recommendations. This 
author's on-site visit flagged these two vital management 
functions (testing and maintenance) as problem areas at 
ISEC.: 


C. SOFTWARE DEVELOPMENT CONTRACTS 


The VFDMIS contract has demonstrated, perhaps all too 


clearly, some of the problems that arise in software 
development contracts. In 1979, the GAO conducted a study 
of software development contracts. Specifically, the study 


included contracts for custom-built applications in the 
federal government. These are the types of contracts ISEC 
would use to procure STAMMIS software from a vendor. The 
report included several causes of problems which were common 
to all contracts GAO reviewed that encountered difficulties. 
Table XIV summarizes the GAO findings. [Ref. 72: pp. 1-31] 
The difficulties of software development are significant 
even when the programmers and analysts are from the same 
organization as the users who need it. Several additional 
sources of difficulty, as described below, are added when 


t 


the software is developed by "outsiders." [Ref. 59: pp. 
7-8] These include: 
l. The problem definition and/or user requirements must 


be defined so that outsiders can understand it; 
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TABLE XIV 


SOFTWARE DEVELOPMENT CONTRACT PROBLEMS IN THE 
GOVERNMENT 


Agencies overestimate the stage of systems 
development they have reache before they 
contract.. 


Contracts fail to stipulate satisfactory 
performance by the contractor. 


Agencies E Y overcommit themselves and fail 
to control contractors through strict phasing. 


Agencies do not manage software development 
contracts during execution. 


OS accept and pay for. software without 
adequately inspecting and testing it. 


Contractors claim that agencies fail to provide 
adequate test data. 


Agencies do not always establish a single focal 
point for communications with contractors. 


Agencies do not adequately SpE CTENI > enforce 


contract clauses for recovery in e event of 


poor performance by the contractor. 


Contractors frequently fail to provide adequate 
software documentation. 





Contracting introduces an extra communication link 
between the software developer and users; 

Contractor personnel must be informed about agency 
operations; 

Agency management must control the quality of work 
done outside the agency; 

First-hand observation of progress is more difficult; 
and 

Acquisition of software from a contractor requires an 
agency to identify and meet all applicable Government 


procurement regulations. 
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With all these problems and complicating factors, it 
seems reasonable to limit software contracts to the absolute 
minimum possible. Because ISEC will continue to use 
contracts as an instrument for meeting mission requirements, 
we need to come to grips with ways to avoid the above 
problems and difficulties. GAO recommends tapping the 
resources of the General Services Administration (GSA) and 
the National Bureau of Standards (NBS) for assistance. This 
author strongly endorses such a recommendation because there 
is no need for duplication of efforts. ISEC should benefit 
by using other government resources. From both a management 
and taxpayer's perspective, this seems logical. 

Besides coordinating with GSA and NBS, the GAO 
recommends training project managers in the overall skills 
necessary to manage these contracts. The training should 
include software engineering, contracting and management. 
GAO also included a checklist in Appendix I of their report 
which provides guidance on contracting for software 
development. [Ref. 59: pp. 29-31] 

A recent article in Datamation provides some excellent 


pointers for solving some of the difficulties enumerated in 


the GAO report. In the article "Negotiating Software 
Contracts", author Charles Harris also provides a software 
contract checklist that appears useful. The article covers 


various steps that relate to project management, negotiating 


strategy and other substantive contract issues. Harris' 
major points are summarized in Table XV below. [Ref. 73: 
pp. 53-58] 


D. PROJECT PLANNING SYSTEMS 
l. Preface 


Much has been written about project management 


process techniques. The rampant problems in software 
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TABLE XV 
GUIDELINES FOR SOFTWARE DEVELOPMENT CONTRACTS 


NEGOTIATION 


e Do not commit yourself too early to_a particular 
vendor or you will lose negotiating leverage. 


e Use the negotiation phase to identify and iron 
out problems and misunderstandings. 


e Follow an organized, professional approach to the 
procurement process to maintain control over the 
negotiating process. 


SPECIFICATION 


e Take the time to adequately document specifica- 
Erons. 


e Consider a separate consulting agreement for the 
vendor to develop the specifications at a fixed 
fee ee the software development contract is 
Signed. 


e An alternative to a consulting agreement is a 
staged software development agreement. The 
user s ability to terminate such a contract is 
beneficial in encouraging the vendor to produce 
iied specifications that are responsive to user 
needs. 


ACCEPTANCE 


e The acceptance procedure may well be the most 
important user provision in any software acquisil- 
tion agreement. 


e Use a realistic acceptance procedure that tests 
each module both separately and sequentially. 


e Tie payments to deliverables. 


WARRANTY, MAINTENANCE and RESTRICTIONS 


e To assure performance after acceptance, Won need 
warranty aņd performance provisions that tailor 
the vendor s response obligations to your partic- 
ular needs. 


e Be sure the contract describes the scope_ and 
response time for all vendor maintenance obliga- 
tions including routine and critical fixes, 
enhancements, and upgrades. 


° any restriction of use (e.g. location, machine or 
site) should be clearly documented. 
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development have provided many issues to write about! Over 
the years, we have become smarter about how to manage 
software development. It is no longer a "shot-in-the-dark 
guestimate." Nevertheless, it remains complex and 
ditficult: We can and should borrow ideas from other 
organizations and adapt them to our own systems. We must 
exercise extreme caution, however, because things like 
definitions and measures need careful explanation before 
they can be implemented in a new environment. 

Measuring productivity, for example, is not 
standardized. There is no accepted industry-wide definition 
of lines of code. What this implies for ISEC is that they 
should "grow their own" system patterned after those 
developed elsewhere. There has been some success with 
project planning systems. Some methods worthy of 
consideration by ISEC are: (Ao) an automated computerized 
project management system; (2) the SLIM system developed by 
Lawrence Putnam (who was employed at CSC (the forerunner to 
ISEC) when he did the research in this area!); and (3) the 
COCOMO system developed by Barry Boehm. They are described 
briefly in the subsections below. There are several other 


estimation models 
2. Project Management Software 


In his book, The Mythical Man-Month, Fred Brooks 


points out that software projects become late one day at a 


time. Not all slips are as dangerous as others. 
How does one tell which slips matter? There is _no 
substitute for a PERT chart or critical path schedule. 
Such a network shows who waits for what. It shows who 


ee the critical path, where any slip moves the end 
ate. 


The preparation of a PERT chart is the most valuable 
ee of its use. Laying out the network, identifying 
he dependencies, and estimating the legs all _force a 
great deal of very specific planning very early ina 
project. The first chart is always terrible, and one 
a and invents in making the second one. [Ref : 
p: 
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One of the problems with PERT (Program Evaluation 
and Review Technique) and CPM (Critical Path Method) 
approaches is that they are not updated as changes occur. 
Many feel that it just is not worth the effort to keep them 
updated. The result is an obsolete PERT or CPM chart that 
is no longer of value. To help solve this problem, there 
are many mainframe and micro-based project management 
software packages available on the market today.?*' 

Mainframe versions such as the Project Tracking 
System by Management Science America keeps track of the 
network critical path, organizes detailed accounting 
information, produces detailed reports of budget variances, 
and even handles nasty overhead allocations. Micro-based 
products provide many of the same features but without all 
the power and depth of mainframe versions. Micro packages 
are flexible, portable, and relatively inexpensive. They 
cost between $200 and $10,000 depending on the features and 
power required. 

Gene Schmidt, a consultant, says the key to 
successful use of project management software is constant 
checking on the actual progress of the programmers and 


analysts. 


The tendency of most systems analysts and programmers is 
not to report productivity problems in the early weeks 


of a project. They always think that they'll make up 
the Lost productivity next week or the week after. By 
carefully checking how much work. has actually been 
completed and re ding this information into the 
computer, e know exac ty where we are on a project at 
any time. Ref. 75: pp. 46-47] 


The May _1985 issue of "Software News" contains two 
articles by Len Horton e several computerized 
project management products. He also includes a list of 
vendors with their addresses. 


107 


There are additional benefits to this type of software. The 
use of project management software wauld be helpful if a 
chargeback system is implemented at ISEC. 

Certainly, project management software is no 
panacea. Dr. Francis M. Webster, an expert on project 


planning software, cautions: 


I have one iece of advice for an manager who is 
thinking about using project management software ae 
Don t ever use_any program to o something ou don t 
understand. If yeu on t at least understand the 
calculations that he Poe eam is making, you can get 
burned. Ref. 76: p. 44] 


He adds later, however, that with the proper understanding 


of project management software, it can be of significant 
value. As Brooks alluded, it forces a discipline on 
management. This author recommends ISEC consider and 


evaluate several available packages for its use. 
3. The Putnam SLIM System 


The project planning software described above does 
not really serve as a planning model for project resource 
estimation but serves more to facilitate the planning 
process. The Putnam SLIM system, however, is a planning 
model. Putnam's model is based on the Rayleigh Curve and 
can be used to estimate the size of medium to large scale 
software projects. From this basic size estimate, Putnam 
presents the methodology for converting the size estimate to 
estimates of time, effort and cost. Putnam suggests the use 
of simulations and linear programming to assist in the 
planning process. [Ref. 77: p. 178] 

The SLIM system is basically a macro approach to 
cost and effort estimation that makes reasonable assumptions 
about the work being done. SLIM is available over 


timesharing services and could serve asa useful first 
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approach to developing a project planning model at ISEC. It 
seems to offer a little less flexibility than you would get 
by developing your own model, but it is probably a good 
place to start investigating the subject. [Ref. 27: p. 53] 
For further information on Putnam's model, the September, 
October, and November (1979) issues of Datamation provide a 


3-part series explaining how to use the model. 
4. The COCOMO System 


Another project planning model worthy of 
consideration is the COnstructive COst MOdel (COCOMO) system 
developed at TRW by Barry Boehm. Boehm provides a detailed 
description of the COCOMO system in his book Software 
Engineering Economics. Boehm has 2 versions of COCOMO. The 
first version is the basic model. It uses the estimated 
number of lines of code and a variable based on 3 modes of 
the estimated complexity of the project (roughly easy, 
medium, or difficult). This is input into an equation that 
Boehm provides resulting in an estimate of the effort 
required to develop the software. Unfortunately, the 
capability of the basic COCOMO system to accurately predict 
the effort within a factor of 2 is only 60 percent. Some 
would argue that this is less than impressive. 

The second version of the COCOMO system is called 
the intermediate model. To the basic model, Boehm adds 15 
factors or "cost driver attributes." The attributes concern 
the product itself (e.g. product complexity), computer 
attributes (e.g. execution time constraints), personnel 
attributes (e.g. analyst capability), and project attributes 
(e.g. use of software tools). Each of these parameters are 
assigned weights (called "effort multipliers" by Boehm), and 
these weights are used multplicatively to adjust parameters 
in the model. Boehm claims that with intermediate COCOMO, 
he is within 20% of the actual results 68% of the time. 
Meet. 27: pp. 53-57] 
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There may be some problems initially testing COCOMO 
at LSEC: Boehm's data base shows few COBOL data points, 
therefore, whether his results are statistically valid (for 
ISEC) is questionable. Further, most of Boehm's data points 
are for applications other than the development of MIS. 
Nonetheless, Boehm gives enough detail about how the models 
are put together that he provides a solid foundation from 
which to build and calibrate your own project planning 
system. COCOMO passes what could be called a "reasonable 
man" test. That is, the parameters in the model are those 
that an experienced professional would probably expect to 
find contributing to effort required in a software 
development project. 

With Boehm's model, GF any other software 
development model, one must be careful how it is applied. 
The development of such an estimation model is an 
evolutionary process. There are many opportunities for 
problems. The process is more an art than a science. IC 
will take time to figure out what the bias caused by ISEC 
measurement practices and how these should be accounted for 
in the model. As technology changes, the model may require 
adjustment. It will probably take a number of years to come 
up with a useful model.!? [Ref. 27: pp. 57-58] 


E. PRODUCTIVITY IMPROVEMENT PROGRAM 


It is difficult if not impossible to isolate the ASDs 
from the their parent organization, ISEC, in terms of 
improving the total STAMMIS effort. Policies and procedures 


at ISEC have considerable impact on the process. If we are 


*"*Graduate students at the Naval Postgraduate School 
(NES are developing a micro-based version of COCOMO an 
the Knowledgeman data base management system. ISEC may wan 
to contact NPS for further information. regarding this 
research. _ The point of contact is Professor Tung Bois 
Administrative Sciences Department, NPS. 
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addressing how to improve STAMMIS development and 
maintenance productivity, we must include the larger system, 
enat is, ISEC. 

There are many approaches to productivity improvement at 
the organizational level. Approaching it in a haphazard way 
invites problems. The best approach for ISEC may not be the 
same for another Army organization. Although this author 
has suggested some possible improvements at ISEC, they must 
be carefully considered and evaluated. Some involve 
training costs, others involve purchasing new tools, and 
still others involve conducting more research (information 
gathering). Because resources are limited, not all the 
recommendations can or should be implemented at one time. 
Tradeoffs must be made. Therefore, some type of mechanism 
for determining these tradeoffs needs to be established. 
One such mechanism is the establishment of a software 
productivity improvement program (SPIP). 

Dr. Barry Boehm provides a multi-step process for 
establishing and tailoring a SPIP in his book Software 
Engineering Economics. [Ref. 29: pp. 682-689] The following 
subsections discuss the multi-step process of implementing a 


SPIP. It is adapted from and based upon Boehm's ideas. 
1. OBTAIN TOP MANAGEMENT COMMITMENT 


If managers do not genuinely want improved software 
productivity, the organization will not get increased 
software productivity. Managers demonstrate their 
intent by actions not merely words. They demonstrate 


their commitment by means of investing in better 


tools, recognizing and rewarding outstanding 
performance, and enforcement of standards, etc. 
Employees are smart. Paying only lip service to 


productivity improvement will alert employees that 


productivity is clearly a "back-burner concern." 
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ESTABLISH A PRODUCTIVITY AGENT 


An old Army principle says "If you want something to 


happen, make somebody responsible." The productivity 
agent serves as the focal point for 
productivity-related issues. Boehm suggests that 


software cost estimation and software data collection 


and analysis activities should be part of the 


productivity agent's charter. This implies two 
things. First; productivity duties should be 
someone's full time job rather than being an 
additional duty. Second, the productivity agent 


should have a close connection with the task force 
for productivity measurement (discussed in chapter 
ae To be effective, the productivity agent should 
report directly to ISEC'’s Chief of Staff or higher. 
It may be tempting to put the responsibilities for 
SPIP on the Quality Assurance Directorate. This may 
be a good short-term solution while studying possible 
internal reorganization or awaiting the formal 
approval of additional spaces to establish a 
permanent SPIP section, but it is not the recommended 


long-term solution. 
ARRANGE BROAD-BASED PARTICIPATION 


Implementing a SPIP brings inevitable changes. 


Allowing the people affected by these changes is good 


management. It stimulates people's enthusiasm rather 
than their resistance. It also provides a more 
accurate assessment of the total environment, Use of 


productivity officers (discussed in chapter 3) may be 
a good mechanism to channel employee ideas and 
Suggestions. This would help ensure communication up 


and down the chain. 
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IDENTIFY OBJECTIVES, ALTERNATIVES, AND CONSTRAINTS 


Boehm says the basic objective is to find ways of 
producing an equivalent level of desired software 
functionality at a reduced cost, with no loss in 
product quality while taking care of employees 
welfare as well. The alternatives to consider are 
the controllable factors such as use of modern 
programming practices, use of software tools and 
improving the work environment. The constraints to 
consider are government regulations, personnel 
cellings, office space limitations, and the hardware 


and software resources available. 


EVALUATE ALTERNATIVES AND CHOOSE THE BEST COMBINATION 


Boehm emphasizes that by far the best results in 


productivity improvement are obtained by working the 


whole problem. There is a potential synergy 
resulting from integrating a combination of 
alternatives. 


PREPARE PHASED IMPLEMENTATION PLAN 


The plan should be incremental with the early phases 
concentrating on the more straight forward, 
easy-to-implement, high payoff items. Like all good 


plans, it must address the "why", "what", "where", 
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who", "when", "how", and "how much" questions. 


OBTAIN THE AUTHORITY TO PROCEED 
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The additional resources required to implement the 


plan for new or increased salaries, equipment, tools, 


training, etc., require the authority to commit funds 
for their procurement. These must be considered as 
an investment. Productivity is not free. One should 
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not expect large increases without some resources to 
achieve them. The farmer who uses a tractor will be 


much more productive than one behind an ox. 
8. IMPLEMENT THE WHOLE PLAN 


Not all parts of a productivity plan may be exciting 
to implement. Getting rid of employees that are 
holding back progress is not a pleasant task but if 
it is not done, the ill effects on other employees 
will cause further damage. Thus, the whole plan 


needs to be implemented, not just the fun parts. 
9. FOLLOWUP AND ITERATE 


The followup implies that ISEC has a measurement 
system in place. Without it, there is no mechanism 
other than "gut feel” to gauge productivity. To 
assist in the measurement problem, Boehm has a series 
of forms that may be helpful in tracking projects. 
These are included in Appendix A of his book, 


Software Engineering Economics. No long-range plan 
is perfect. What is good today may not be so 
tomorrow. The "iterate" portion of this step allows 


for the fact that the SPIP is evolutionary and should 


be changed as needed. 


Boehm, in another article that he co-authored, makes 
some additional points about SPIP and productivity 
improvement that are important. Table XVI summarizes these 
points. Some are redundant with material presented earlier 
but are worth repeating. [Ref. 3: pp. 30-42] 

Finally, Boehm reminds us that improved software 
productivity is not an end in itself. It is a means to help 
people better expand their capabilities to deal with data, 


information, and decisions. He emphasizes that the software 
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TABLE XVI 
KEY POINTS - SOFTWARE PRODUCTIVITY IMPROVEMENT PROGRAM 


Significant software mee Oe ea improvements 
are not achieveable without the ull commitment 
of higher management. 


The best an to get started on a sustained SPIP 
is to establish a software productivity agent. 


Significant productivity gains require, an inte- 
grated program of initiatives in several areas. 


An integrated can have an extremely large payoff. 


Improving software productivity involves a long, 
sustained effort. 


In the very long-run, the biggest oe ee VEY. 
e O 


gains will come from, increasing, t use 
existing software (tools and utilities suitable 
for reuSe). 





productivity scoreboard is just one of many ways we have to 
gauge our progress toward becoming more efficient data 


processing professionals. [Ref. 29: p. 689] 


Besides the practical advice of Dr. Boehm on SPIPs, 
Sumanth provides some useful information on (generic) 
productivity improvement programs. Condensed in Table XVII 


are common problems with productivity improvement programs 
and how to avoid these pitfalls. [Ref. 22: pp. 483-486] 


F. SUMMARY 


This chapter has discussed a number of relevant 
management barriers to productivity. Contract management 
problems and solutions were identified. Project planning 


systems were explained. A recommendation was made that ISEC 


Should begin preliminary work on developing a project 
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establishing a software productivity 


Such a program given. 


TABLE XVII 
PRODUCTIVITY IMPROVEMENT PROGRAM PROBLEMS AND 
SOLUTIONS 
Resistance to Change 


+ Get employees involved. _Establish appropriate 
financial and non-financial incentives. 


Inadequate Planning 
° Care rU plan the program and its implementa- 
tion. Brainstorm possible problems and develop 
prevention strategies. 
Modification in Data Collection 


e Develop a ae system. Test this system with 
hypothetical data. 


"It's Not My Program Syndrome” 
e Consult employees before the program is estab- 


lished for their ideas and suggestions. Make the 
employees a part of the program. 


e Carefully evaluate the results. Don't read more 
into the results than is actually there. Look at 
the big picture. Ensure incentives do not 


encourage Se eos to suboptimize some aspect to 
the detriment of the total process. 


Unwillingness to Share Productivity Gains 


e Recognize emp To een that contribute to the effec- 
tiveness of the program. Without any incentives, 
long-term commitment to the program will be 
threatened. 


Tendency to Compromise Quality for Productivity 
e Managers and employees must be trained that 


quality and productivity are related. Both are 
important. 
planning and effort estimation model. The framework for 


ISEC was outlined and the benefits and potential problems of 
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improvement program at 


This author recommends ISEC initiate 


the planning for integrated software productivity program 
soon. Although there are definite short-term expenses to be 
shouldered, the long-run payoff can be extremely high. 

The next and final chapter provides the author's 
conclusions and recommendations for productivity improvement 
at ISEC with particular emphasis on the STAMMIS development 
and maintenance process. It also provides recommendations 


for areas requiring additional research. 
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VII. CONCLUSIONS AND RECOMMENDATIONS 


A. THESIS SUMMARY 


This is a report of the productivity enhancement study 
of the ISEC STAMMIS development and maintenance effort. The 
Study is an initial effort to identify candidate practices, 
areas and projects for productivity improvement. We have 
reviewed the STAMMIS development and maintenance process at 
ISEC and have identified problem areas. To solve these 


problems and improve productivity at the programmer, project 


and organizational levels, the entire process was examined 
for candidates for improvement. Four major areas were 
suggested for improvement: methodology, management, 


technology, and the software development environment. 

Under the methodology umbrella, problems with the 
traditional software life cycle and specification process 
were emphasized. An alternative life cycle using 
evolutionary development was suggested. The advantages and 
limitations of prototyping were discussed. In addition, the 
applicablity of prototyping at ISEC was established. 
Probably the most important contribution of prototyping and 
evolutionary development is that they tear down the walls of 
misunderstanding and miscommunication thus bringing users 
and developers together. 

Several management issues were raised. Problems with 
software contract management were explored. Some 
suggestions for prevention of these problems were offered. 


Helpful hints about the negotiation of contracts were also 


provided. Project planning was discussed and a few possible 
approaches were presented. The need for a productivity 
improvement program at an organizational level was 
established. 
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The total software development and maintenance 
environment was considered. To assist in prototyping and 
structured systems development, a unified software tool set 
is a necessity. At the heart of this tool set is an 
integrated and active data dictionary. It provides a basis 


for a record management system and automates much of the 


documentation process. The environment also includes the 
human factors involved in the software process. These are 
such things as the physical work space, the training 
program, the awards and incentives program, compensation, 
etc. Several of these are candidates for improvement at 
ESEC. 

Productivity was defined and distinguished from 
production, efficiency, and effectiveness. The problems 


associated with measuring performance was contrasted with 
the handsome benefits that measurement offers. Some 
guidelines were included to aid in the proper evaluation of 
productivity measures. Several productivity measures for 
software development and maintenance were explained and 
evaluated. Finally, a strategy for implementing a 


productivity measurement system at ISEC was presented. 


B. RECOMMENDATIONS 


To be as useful and realistic as possible, the study 
included five days of on-site interviews and observations in 
addition to the review of several dozen working documents at 
ISEC and over one hundred articles and books related to this 
study. Although a longer on-site period followed by a 
second visit to probe some areas more thoroughly would have 
been optimal, the results should be valuable to ISEC. They 
provide an outsider's view of problems and potential 


solutions relating to the entire software process. 
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The major recommendations (in relative order of 
importance) in this report are described below. 

l. ISEC should seek a unified software tool set that 
will support all facets of software development and 
maintenance. The tools chosen Should support 
prototyping and communicate with each other. 

2. Prototyping/Evolutionary development should be 
adopted as the preferred methodology for requirements 
Specification and systems development. They reduce 
project risk, yield systems which better reflect user 
needs, and usually reduce development time and 
manpower requirements. 

3. The implementation of a productivity measurement 
system will help ISEC's management in planning, 
controlling, and evaluating the software development 
and maintenance process. 

4. ISEC software contract management needs revamping. 
ISEC needs to train itS management in appropriate 
contracting areas. 

5. ISEC should seek the help of other federal agencies 
(such as the GAO, GSA, and NBS), and DOD 
organizations (such as the National Security Agency, 
Air Force and Navy) to improve all aspects of the 
software process. There is no need to reinvent the 
wheel; a suitable framework, at least, probably 
exists at one of these organizations. 

6. The physical facilities at ISEC are far from ideal. 


In need of improvement are the amount of work space 


per employee, the number of terminals, the computer 
response time, the number of conference rooms for 
reviews and walkthroughs, use of office automation, 


and the heating/air conditioning system. 
The above suggestions should be incorporated into a total 


software productivity improvement program (SPIP). The SPIP 
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would include a clear statement of organizational produc- 
tivity objectives and a carefully thought-out plan _ to 
achieve them. The SPIP might include some promising produc- 
tivity features such as tailoring a library of reusable code 
or creating an information center to support end-users. 
Results in some commercial organizations demonstrate that 


productivity could double within two years with a SPIP and 


the long-run gains may be even more spectacular. (Ref. 3; 
p. 33] Organizational commitment is critical to the success 
of the program. It should start with top management and 


echo through all levels of the organization. 


C. RECOMMENDATIONS FOR FURTHER STUDY 


During the author's on-site visit and literature review, 
several intriguing issues surfaced that may deserve study or 
further analysis. These issues/areas for further study (in 
no particular order) are discussed below. 

l. Conduct a detailed analysis of software tools 
applicable for ISEC addressing such issues as "What 
is currently on the market?", "What do ISEC managers 
and programmers want?", "What can ISEC afford?" and 
"How can ISEC speed up their software tools 
acquisition and training program?” . 

Zee Conduct a feasibility study identifying and 
quantifying the costs and benefits of the Army 


adopting a single operating system such as MVS for 


STAMMIS. 

3. Conduct a capacity planning analysis of the computer 
resources available for STAMMIS development and 
maintenance. 

4. Participate ii the preliminary planning and 
requirements analysis for the establishment of 


STAMMIS corporate data base. 
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1G, 


Although DOD and General Paige seem committed to Ada, 
a detailed cost/benefit analysis of it might be 


‘enlightening. 


Conduct and analyze a series of employee surveys 
regarding: (1) their perception of problems at ISEC; 
(2) their ideas and suggestions for improving 
productivity; and (3) what motivates them. 

Conduct an analysis concerning the effect of a 
chargeback system (.e.g. billing DCSPER for SIDPERS 
maintenance work) on STAMMIS functional proponents, 
user demand and user perceptions. The study might 
include the best criteria to bill the FPs and propose 
an implementation plan for installing such a 
chargeback system. 

Conduct a review and analysis of good ideas already 


in practice in other federal and DOD organizations 


concerning: (1) contract management ; (2) 
productivity measurement; and (3) productivity 
improvement programs; (4) software development 
environments; (5) awards and incentive programs; and 


(6) software tools in use. 

Conduct a feasibility study for the collocation of 
all ISEC programming directorates with their FP 
counterparts. 

Conduct research to determine what project planning 
system would be most useful for ISEC. Micro-based 
systems, the Putnam SLIM system, and the COCOMO model 
are some potential candidates for consideration at 
TSEC. 
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ACSIM 


AESEIC 


ASD 


COA 


COBOL 


CPM 


CPO 


CSC 


DA 


DCSIM 


DCSLOG 


DCSPER 


DOD 


ESSD 


FORTRAN 


PP 


GAO 


APPENDIX A 
ACRONYMS 


Assistant Chief of Staff for Information 
Management 


U.S. Army Electronics System Engineering 


and Installation Command 

Assigned System Developer 
Comptroller of the Army 

COmmon Business Oriented Language 
Critical Path Method 

Civilian Personnel Office 

U.S. Army Computer Systems Command 
Department of the Army 


Deputy Chief of Staff for Information 


Management 


Deputy Chief of Staff for LOGistics 


Deputy Chief of Staff for PERsonnel 
Department of Defense 

Executive Systems Software Directorate 
FORmula TRANslation 

Functional Proponent 


General Accounting Office 
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GSA 
HOL 
HOM 
HOS 
IBM 
IE 

IMA 
IRM 


ISEC 


ISSSC 


MILPERCEN 
MIS 

MVS 

NBS 

NPS 

NSA 

OMB 

OJT 

PC 

FERT 


PQ Teams 


General Services Administration 
Higher Order Language 

Higher Order Machine 

Higher Order Software 

International Business Machines, Inc. 
Information Engineering 

Information Mission Area 

Information Resource Management 


U.S. Army Information Systems 


Engineering Command 


U.S Army Information Systems Software 


Support Command 

MILitery PERsonnel CENter 
Management Information Systems 
Multiple Virtual System 
National Bureau of Standards 
Naval Postgraduate School 
National Security Agency 

Office of Management and Budget 
On-the-Job-Training 

Personal Computer 

Program Evaluation and Review Technique 
Productivity and Quality Teams 


Resource Allocation Tool 
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RDC 


SAILS 


SARSS 


SDLC ` 


SIDPERS 


SPIP 


STAMMIS 


STANFINS 
STARCIPS 


CIEE- UP 


ULLS 
USA 
USACC 
USAISC 
VIABLE 


VFDMIS 


VTAADS 


Regional Data Center 


Standard Army Installation Logistics 


System 


Standard Army Retail Supply 
System 


Systems Development Life Cycle 


Standard Installation/Division PERsonnel 


System 


Software Productivity Improvement 


Program 


Standard Army Multi-command Management 


Information System 
STANdard FINance Systems 
STandard ARmy CIvilian Payroll System 


Systems Through an Evolutionary 


Process Using Prototyping 

Unit Level Logistics System 

United States Army 

U.S. Army Communications Command 

U.S. Army Information Systems Command 
Vertical Integrated Automation BaseLinE 


Vertical Force Development Management 


Information System 


Vertical The Army Authorization 


Document System 
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APPENDIX B 
USING GRADUATE STUDENTS TO IMPROVE PRODUCTIVITY 


This author contends that Army organizations such as 
ISEC should actively tap the pool of talent of Army 
fully-funded advanced degree students (and possibly other 
Armed Forces students) to the maximum extent possible. Most 
Students must complete a thesis to fulfil their degree 
requirements. Many have no idea what they would like to do 
their research on. It makes economic sense to obtain a 
return on the Army's investment in their education (in 
addition to their service obligation). 

To actively recruit students for thesis work will 
require 3 things. 

l. ISEC will need to identify target projects in 
"thesis-sized chunks". Large projects will have be 
logically decomposed. 

2. ISEC will need to budget TDY funds for research 
expenses. Typically; expenses for a thesis range 
from $1000 tome 30007 There are many variables 
involved but a good planning figure would be $2000 
per study. 

3. ISEC should send knowledgeable representatives who 
relate well to students to market their theses 
research topics. Timing of these visits is critical 
to the success of the program. Too late and everyone 
already has a topic; too early and no one will know 
what they want to do. 

Remember that each student has at least one and usually 
two PhDs for advisors so the quality of the product is 
generally good. Using Army students to solve Army problems 


helps everyone. It is a viable alternative to using 
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consultants or in-house assets. To ignore the student 
knowledge-base is to waste an Army resource. 

Besides the students, the faculty at many educational 
institutions are always looking for interesting research 
work. They have a special expertise worth considering for 
those projects which ISEC cannot (for whatever reason) do 
themselves or which are beyond the scope of student thesis 


work. 
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